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Program  Chair’s  Statement 

Th«  go '  ’  -it  the  STARS  program  is  to  increase  productivity,  reliability,  and  quality  of  DoD 
applicau  Ju  software.  STARS  is  approaching  this  by  synergistically  integrating  support  for  modem 
software  development  processes  and  modem  reuse  concepts  within  state-of-the-art  software 
engmeeiing  environment  technol''gy.  STARS  is  focxised  on  accelerating  a  change  in  the  way 
software  is  developed  within  the  OoD.  This  change  represents  a  shift  to  a  megaprogramming 
paradigm. 

The  STARS  program  would  like  you  to  ’Join  us  in  the  transition  to  megaprogramming."  The 
conference  program  has  been  designed  to  introduce  you  to  the  concepts  of  megaprcgramming  and 
describe  the  role  STARs  is  playing  in  the  transition  to  this  new  paradigm.  The  plenary  session 
wiU  provide  }rou  a  high  level  overview  as  well  as  some  economic  analysis  of  the  potential  beneftts  of 
megaprogramming. 

The  closing  discussion  by  Dr.  Barry  Boehm  will  describe  the  relationship  of  megaprogramming  and 
STARS  to  the  DoO  Software  technology  plan. 

Three  of  the  four  track  sessions  will  focus  on  the  major  elements  of  megaprogramming; 

•  Process-driven  devek  -roent, 

•  Domain-specific  reuse,  and 

•  Technology  support. 

The  fourth  track  will  concentrate  on  the  STARS  technology  transition  activities  associated  with 
accelerating  the  shift  to  this  new  way  of  doing  busicest.  The  format  of  these  track  sessions  is 
intended  to  provide  ample  opportunity  for  discussion  and  informal  interchange. 

The  STARS  program  needs  yovcr  help  to  move  these  concepts,  processes,  and  technologies  into 
widespread  use.  To  this  end,  we  are  soliciting  you  to  become  part  of  the  STARS  Affiliates 
program.  The  STARS  Director,  John  Foreman,  will  describe  the  program  during  the  plenary 
session  and  there  will  be  evening  sessions  for  those  of  you  considering  becoming  Technology 
Transition  Affiliates  to  discuss  your  interests  with  members  of  the  STARS  staff. 

My  sincere  thanks  go  to  the  members  of  the  program  committee  who  coordinated  the  selection  of 
topics  and  the  development  of  the  presentations.  Most  of  the  credit  for  the  program,  however, 
must  go  to  the  individual  presenters  who  put  s  great  deal  of  personal  effort  into  creating  the  34 
presentations  you  have  in  your  proceedings. 

I  would  also  like  to  thank  the  conference  chair,  Don  Harmon,  the  conference  committee,  and  the 
publications  staffs  for  a  splendid  job  of  organizing  this  conference.  And  finally,  my  special  thanks 
to  BGen  Denis  Brown  for  making  time  in  his  schedule  to  address  us  at  STARS’  91. 

Dick  Drake 

Program  Chair,  STARS  '91 

IBM  Corporation 

800  North  Frederick  Ave. 

Gaithersburg,  MD  20879 

Internet:  DDrakeOAJPO.SEI.CMU.EIdu 
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Day  2,  Wednesday,  December  4, 1991 


STARS  ’91 

PLENARY  SESSIONS 


Ibesday  December  3,  1991 

8:30-8:45 

STARS  '91  Overview 

Don  Hannon,  Unisys  Defense  Systems,  Inc. 

8:45-9K>5 

SIARS  and  Megapregramming 

Dr.  Bony  Boehm,  DARPA 

9:05-9:45 

STARS  Vision,  Mission,  Strategies 
and  Achievements 

John  Fortman,  DARPA 

9;45-10;l5 

Break 

10:15-10:45 

Economic  Impaa  of 
STARS-Supponed  Technology 

Dr.  Thomas  P.  Frazier,  IDA 

10:45-11:15 

Technology  Transfer  and 

Gimmunity  Involvement 

John  Fortman,  DARPA 

11:15-11:45 

Questions  and  Answers 

John  Fortman,  DARPA 

STARS  ’91 

PLENARY  SESSIONS 


Wednesday  December  4,  1991 

3H>0-3;40  DoD  SofTvare  Technology  Plan 
and  STARS 

3^4<MH)0  Final  Remarfcs/Oosing 


Dr.  Bony  Bedim,  DABPA 
John  Fortman,  DARPA 
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STARS  ’91  OVERVIEW 


Don  Hannon 

Unisys  Defense  Systems,  Inc. 

3  Deamber  1991 
(703)  620-7559 

hannon@stars.reston.unis)S.com 


Good  moming!  Welcome  to  STARS’91.  Let  me  spend  the  first  few  minntes  explaining  onr  program  so  yon  can  get 
the  most  out  (A  the  next  two  days. 

Onr  oonferena  theme  is  “Join  The  Ihuisition  to  Megaprogramming”  and,  consistent  with  this  theme,  we  have 
selected  some  ambitious  goals  and  objectives  for  onr  [trogram.  In  STARS’91,  ws  will  provide  you  with  detailed 
presenutions  and  demonstrations  of  our  results  to  date  and  obtain  feedback  from  you.  .^d  we  will  tell  you  how  your 
organiation  can  join  in  the  transition  to  megaprogramming. 

If  you  look  toward  the  saeen  you  can  see  where  we  have  summarized  the  STARS’91  goals. 
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STARS  ’91  OVERVIEW 


CONFERENCE  GOALS  AND  OBJECTIVES 


•  Global 

-  Discuss/explore  the  economic  impact  of  STARS  supported 
technology 

-  Accelerate  transition  to  megaprogramming 

•  Technical 

-  Review  progress  in  STARS  technology  thrusts 

-  Demonstrate  work  in  progress 

-  Give  insight  into  upcoming  plans 

-  Obtain  feedback 

•  Opportunities  to  participate 

-  Elxpand  Technology  Transfer  Affiliates  program 

-  Preview  plans  for  demonstration  projects 


We  sun  wiUj  Uie  global  objectives  of  discussing  the  economic  benefits  of  STARS  supponed  technology  and  of 
accelerating  the  transition  to  megaprogramnung. 

Our  technical  goals  consist  of  reviewing  STARS  technical  work,  and  secondly— getting  yonr  feedback  on  this  worL 

We  also  will  present  opportunities  for  you  to  participate  with  STARS.  In  part  this  will  come  from  an  expansion  of  our 
Technology  Transfer  Affiliates  Program,  and,  in  part,  previewing  the  plans  for  our  Demonstration  Projects. 

Not,  let  me  go  over  the  highlights  of  our  program. 
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STARS  ’91  OVERVIEW 

_ fflGHLIGHTS _ 

•  Keynote  Speakers 

-  STARS  and  Megaprogramming:  Barry  Boehm  (DARPA) 

-  DoD  Software  Technology  Plan  and  STARS:  Barry  Boehm  (DARPA) 

-  STARS  Vision,  Mission,  Strategies,  and  Achievements: 

John  Foreman  (DARPA) 

-  Technology  Transfer  and  Community  Involvement:  John  Foreman 
(DARPA) 

-  Economic  Impact  of  STARS  Supported  Technology:  Tom  Frazier  (IDA) 

•  Four  Parallel  T^cks 

-  Process  Driven  Development:  Dick  Drake  (IBM) 

-  Domain>Specific  Reuse  :  Teri  Payton  (Unisys) 

-  Technology  Support:  Larry  Frank  (Boeing) 

-  Technology  IVansition:  Joe  Morin  (SEI) 

•  Technology/Tool  Demonstrations 

•  Evening  Reception  and  Informal  Discussion  Groups 

-  Invited  Speaker:  Denis  Brown  (DISA/CIM)  ^ 


STARS’^!  is  fortnnste  !0  have  several  distinguished  keynote  q)eaker5  who  will  present  the  overall  STARS  strategy. 
These  include  Dr.  Barry  Toehm,  Director  of  OARPA/SISTO,  who  will  talk  on  “STARS  and  Megaprogramming"-  Dr. 
Boehm  will  also  be  on  our  program  tomorrow  to  discuss  the  “DoD  Software  Technology  Plan  and  STARS".  John 
Foreman,  the  DARPA/STARS  Program  Director,  will  discuss  the  “STARS  Vision,  Mission,  and  Strategy  and 
Achievements",  as  well  as  a  second  talk  on  ’Technology  Transfer  and  Community  Involvement".  We  also  have  Dr. 
Thomas  P.  Frazier  who  will  provide  some  insight  into  the  “Economic  Impaa  of  STARS  Supported  Technology". 

The  main  body  of  our  program  will  feature  four  tracks.  These  will  be  led  by  the  three  STARS  System  Architects: 
Dick  Drake  of  IBM,  Teh  f^yton  of  Unisys,  and  Larry  Frank  of  Boeing.  The  fourth  Track,  Technology  Transfer,  will 
be  led  by  Joe  Morin  of  the  SEI. 

We  are  fortunate  to  have  Denis  M.  Brown  (BCen  USAF,  ReeX  Director  of  DISA/CIM,  as  our  invited  guest  speaker 
this  evening.  Finally,  we  have  a  reception  planned  for  this  evening  to  be  followed  by  informal  discussion  groups.  You 
will  hear  more  about  these  from  the  Ikack  Chairs. 

Neirt,  our  administrative  announcements. 
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STARS  ’91  OViiRVIEVV 

ADMINISTRATIVE  ANNOUNCEMENTS 

^9 

•  Registrants  receive  full  STARS  ’91  proceedings 

•  Attendee  list  available  tomorrow 

•  STARS  ’91  posters  available 

•  Administration  information  available  in  registration  package 

•  Messages,  fax 

Each  of  you  should  have  a  3-niig  binder  containing  the  STARS'91  Proceedings.  This  binder  contains  copies  of  all 
bnefings.  Tomorrow  we  will  have  copies  of  the  attendee  lists  available  at  the  registration  desk  which  can  be  added  to 
the  presentation  materials. 

STARS'91  posters  are  also  available  at  the  registration  desk.  Please  help  yourself. 

If  you  want  to  mail  material  back  to  your  home  station,  you  can  take  advantage  of  our  mailing  service  located  in  the 
lobby.  You  will  also  Find  a  rr.essage  center  there  for  telephone  calls. 
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STARS  ’91  OVERVIEW 

FLOW  OF  ACTIVITIES,  DAY  1 


Time 

Event 

7:30am-8:30am 

Registration  and  continental  breakfast 

8:30ain-8:45am 

STARS  ’91  overview 

Den  Harmon  (Unisys) 

8:4Sain-9:05am 

STARS  and  Megaprogramming 

Barry  Boehm  (DARPA) 

9H)5am-9:4Sam 

STARS  Vision,  Mission,  Strategy,  and 
Achievements 

John  Foreman  (DARPA) 

9:4Sam-10:15am 

Break 

10:lSam-10:4Sam 

Economic  impact  of  STARS  Supported 
Technology 

Tom  Frazier  (IDA) 

10:4Sam-ll:lSam 

Technology  IVansfer  and  Community 
Involvement 

John  Foreman  (DARPA) 

ll:lSam-ll:45am 

Questions  and  Answers 

John  Foreman  (DARPA) 

ll:4Sam-2:00pm 

Demonstrations  (buffet  lunch  available) 

OmmmrtHmmm/yCS 


At  a  glance,  here  are  this  moniing’s  activities.  Note  that  th^  all  tahe  place  here  in  the  Grand  Ballroom.  Our 
keynote  ^>eaker$,  Bany  Boehm,  John  Foreman  and  Tom  Frazier  will  provide  the  strategic  themes  that  establish  the 
context  for  STARS,  tie  the  various  pieces  of  the  program  together,  and  provide  an  overview  of  future  plans.  John 
Foreman  will  close  this  rooming’s  sessions  with  a  Q  &  A  period. 

Starting  at  11:45  we  have  an  extended  lunch  period.  This  provides  you  with  an  opportunity  to  visit  the  demonstrations 
and  exhibits.  These  are  setup  in  the  Junior  Ballroom  which  is  adjacent  to  the  dining  area. 
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STARS  *91  OVERVIEW 

DEMONSTRATIONS  AND  EXHIBITS 

•  STARS-sponsored  technology  demonstrated  in  STARS  booth 

•  Invited  CASE  tool  vendors  in  exhibit  area 

-  Emerging  technology  compatible  with  STARS  vision/mission/strategy 
and  some  commercial  developments  based  on  STARS  technology 

-  Support  unique  DoD  needs  (i.e.,  Ada,  2167A) 

-  Recommended  by  STARS  primes  and  their  commercial  counterparts 

-  In  general,  demonstrated  capabilities  are  commercially  available 


ehmmmlHmmm/yq 


Next  let  me  digress  a  minute  and  talk  about  the  STARS‘91  Exhibits  and  Demonstrations.  These  consist  of  a  STARS 
booth  in  which  STARS-^)onsored  technology  is  demonstrated.  The  STARS  booth  is  located  just  inside  the  Lord 
Fairfax  room  where  we  will  have  our  buffet  lunch.  In  the  adjoining  Junior  Ballroom,  the  invited  CASE  Tool  vendors 
will  hold  their  demonstrations.  These  companies  have  been  seleaed  because  their  products  are  consistent  with  the 
STARS  vision,  mission  and  strategy. 


( 


{ 
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STARS  ’91  OVERVIEW 

FLOW  OF  ACUVITIES,  DAY  1  (CONTINUED) 


lime 

Event 

2:00pm-2:45pm 

lyackl.l  jlVack2.1 

Hack  3.1 

Hack  4.1 

2:45pm-3:15pm 

Break/informal  discussions 

3:15pm-4HX)pm 

Hack  1.2 

Hack  2  J 

Hack  3.2 

Hack  42 

4:00pm-4 :30pm 

Break/informal  discussions 

4:30pm-5:15pm 

HacklJ 

Hack  2-3 

Hack  3.3 

Hack  4J 

5:30pm-6:00pm 

Invited  speaker:  Denis  M.  Brown  (DISA/OM) 

6:00pm-8:00pm 

Demonstrations  and  reception 

8K)0pm-9l30pm 

Community  involvement  working  sessions 

Hackl 

Hack  2 

Hacks 

Hack  4 

OmmgrntUmmm*  VC7 


This  afternocn  we  will  hiesk  into  the  parallel  tracks.  Within  each  track  there  will  be  six  sessions  of  45  minutes 
followed  by  a  thirty  period  of  informal  discussions  and  break.  On  this  vu-graph  the  notation  Track  x.y  is  used,  where 
X  is  numbered  1  to  4  to  indicate  one  of  the  four  tracks,  and  y  indicates  the  session  within  the  track.  Generally,  people 
will  want  to  stay  within  a  track,  but  the  breaks  are  siructnred  so  that  individuals  can  cross  from  one  track  to  another. 
Track  room  ^gnments  are  shown  on  the  signs  outside  this  meeting  area. 

This  evening  we  continue  with  the  demonstrations  and  exhibits  in  the  Junior  Ballroom  plus  a  reception  has  been 
scheduled.  And  later,  starting  at  8  pm  we  have  informal  working  discussions.  You  will  hear  more  about  these  in  the 
Irack  se^ns.  Also  don’t  forget,  Denis  M.  Brown  will  speak  at  5:30  in  this  room. 
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STARS  ’91  OVERVIEW 

FLOW  OF  ACnVITIES,  DAY  2 


Time 

Event 

7:30am-8:30am 

Registration  and  continental  breakfast 

8:30am-9:15am 

lVackl.4 

Tback2.4 

Tback3.4 

TVack4.4 

9:15am-9:45am 

Break/informal  discussions 

9:45am-10:30am 

Tbackl.S 

IbaGk2.S 

Thick  3.5 

TVack4.5 

10:30am-lld)0affl 

Break/informal  discussions 

lld)0am-ll:45am 

TVackl.6 

iyadi2.6 

TVack3.6 

TVack  4.6 

ll:45am-l:45pm 

Demonst  tions  (bufTet  lunch  available) 

OmrmmiHmmmiyCt 


Day  2  contiooes  with  the  parallel  llack  sessions.  The  lunch  and  demo  period  will  be  the  same  as  on  the  previous  day. 
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STARS  ’91  OVERVIEW 


FLOW  OF  ACTIVITIES,  DAY  2  (CONTINUED) 


Time 

Event 

l:45pm-2;30pm 

Tback  1  feedback 
session 

IVack  2  feedback 
session 

TVack  3  feedback 
session 

Tback  4  feedback 
session 

2:30pm-3:00pm 

Break 

3:00pu-3:40pm 

DoD  Software  Technology  Plan 
and  STARS 

Barry  Boehm  (DARPA) 

3:40p>D— 4:00pm 

Closing  remarks 

John  Foreman  (DARPA) 

After  lunch,  there  will  be  a  final  Ihtck  Feedback  session  conduaed  by  the  STARS  Program  Managers.  This  is  a 
general  feedback  session  so  attend  the  one  for  the  Track  you  have  been  most  involved  with.  And  then  starting  at  3 
pm,  a  final  plenaiy  session  will  be  held.  Be  sure  to  stay.  Dr  Boehm  will  be  talking  about  the  DoD  Software 
Technology  Plan  and  STARS,  and  John  Foreman  will  summarize  significant  issues  raised  during  the  Conference  and 
point  out  where  we  need  to  go  from  here. 
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My  final  vngnpli  shows  the  locacioa  of  the  major  meeting  areas,  lb  help  you  find  the  Ttack  rooms,  signs  are  located 
right  outside  this  meeting  area. 


i 


i 


Now  to  begin  our  Program,  I  would  like  to  introduce  you  to  Dr.  Barry  Boehm  who  is  the  Director  of  DARPA/SISTO 
which  is  the  U.S.  government’s  largest  computer-communication’s  research  organization.  He  will  ^peak  to  us  on 
“STARS  and  Megaprogramming”. 


Dr.  Boehm  — 


i 
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STARS  AND  MEGAPROGRAMMING 


Barry  Boehm 
DARPA 
STARS  ’91 
3  December  1991 


STAMS  mA 


STARS  AND  MEGAPROGRAMMING 

OUTLINE 


•  The  Megaprogramming  Vision 

•  Critical  Success  Factors 

•  STARS  and  Megaprogramming 

•  The  Bottom  Line 


STARS  AND  MEGAPROGRAMMING 

COMPOSING  SW  COMPONENTS  RATHER 
THAN  LINES  OF  CODE 


Machine  Language 
Programming 


Assembijf  Language 
Programming 


FORTRAN,  C,  Ada 
Programming 


Megaprogramming 


Seven  League  Bools 


STARS  AND  MEGAPROGRAMMING 

MEGAPROGRAMMING  BENEFITS 


•  Development  productivity 

-  Fewer  components  to  assemble^  integrate,  test 

-  Smaller  teams;  less  overhead 

>  Opportunities  for  application  generators 

•  Maintenance  productivity 

-  Update  (40%):  open  interfaces;  alternative  components 

-  Adaptive  (25%):  open  interfaces  to  infrastructure  software  and 
hardware 

-  Corrective  (25%) :  fewer  residual  errors;  effects  encapsulated 

•  Reliability,  Availability,  Security 

-  Proven  vs  unproven  components 

•  Portability,  Interoperability 

-  Well-defined  open  interfaces 

•  Operational  Capability 

-  Darwinian  evolution  of  best  components 

-  Accommodates  hardware  technology  improvements 


14 


Annua]  DoD  Soltwarc  Cost  <Thcn-Ycar  SB) 


STARS  AND  MEGAPROGRAMMING 

PROGRAM  RESULTS  BY  SOURCE  OF 
SAVLNGS 


Baseline  Total 


Work  Avoidance 
(Reuse) 


■f  Working  Smarter 


■f  Working  Faster 
(Too>s) 


1992  1994  1996  1998  2000  2002  2004  2006  2008 


STARS  AND  MEGAPROGRAMMING 

MEGAPROGRAMMING  PARADIGM  SHIFTS 


Not  programming  as  taught,  practiced  today 

-  Requires  higher  levei  of  thinking,  engineering 

Evolution  and  opportunity-oriented  rather  than  “requirements 
snapshot”  orient^ 

-  Supports  continuous  system -level  improvement 

Requires  domain  expertise,  assets  as  well  as  programming  expertise, 
assets 

Requires  open-systems  approach 

Evolutionary  progress  feasible 

-  Doesn’t  depend  on  unpredictable  breakthroughs 
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STARS  AND  MEGAPROGRAMMING 

MEGAPROGRAMMING:  CRITICAL 
SUCCESS  FACTORS 


•  Life  cycle  process  models  supporting  architecture-oriented  software 
evolution 

•  Software  component  composition  principles  and  open  interface 
specifications 

•  Domain -specific  software  architectures  (DSSA) 

•  Software  asset  libraries  and  access  mechanisms 

•  Software  engineering  environments  with  built-in  megaprogramming 
support 

•  Software  understanding  and  re-engineering  support  at  the  component 
level 

•  Policy  support  of  the  above 


STARS  AND  MEGAPROGRAMMING 

WRONG  PROCESS  MODELS  CAN 
DISCOURAGE  REUSE  ~  e.g.,  Waterfall  Model 


Baselined; 


Ibob  and  enviromnenta  buQt  to  mterCall  model  will  also  discourage  reuse. 


Xt4ia  tmIm/VOt 


STARS  AND  MEGAPROGRAMMING 

.  DSSA  PROGRAM  SUMMARY  CHART 


Domain  Specific  Software  Architecture 


^>OM^^ 


Aeionics 

IBM/Ua/UTex 

Wright  Labs 

Command  and  Control 

GTE  ContelAJSC-ISI 

GMU 

CECOM 

Vehicle  Management  Systems 

TFS/Stanford 

ARDEC 

Guidance,  Navigation  &  Control 

Honeywell/UMd 

ONR/NAWC 

Distributed  Intelligent  Control 

ORA/Comell  MSI 

ARDEC 

Prototyping  Technology  Insertion 

TRW/Stanford 

ONR 
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STARS  AND  MEGAPROGRAMMING 

OUTLINE 


•  The  Megaprogramming  Vision 

•  Critical  Success  Factors 

•  STARS  and  Megaprogramming 

•  The  Bottom  Line 


STARS  AND  MEGAPROGRAMMING 

TARS  SUPPORT  OF  MEGAPROGRAMMING 


Megaprogramming  Critical  Success 
Factors 

STARS  Support 

•  Process  models 

•  Reuse  processes 

•  Process  Asset  Library 

•  Composition  principles 

•  Demonstration  projects 

•  DSSA’s 

•  Domain  analysis  process 

•  Asset  management 

•  Asset  libraries 

•  ASSET,  ALOAF 

•  DoD  Reuse  Coordination 

•  SEE  support 

•  SEE/Library  coupling 

•  SEE/Reuse  process 

•  Policy  Support 

1 

i 

•  Demonstration  projects,  other  tech 
transition  activities 

STARS  AND  MEGAPROGRAMMING 

STARS  INTERACTIONS  WITH  DARPA 
SCIENCE  AND  TECHNOLOGY  PROGRAM 


Software  {  i 
Component  V  E 
Commerce 
Cooperative  Work 


Internet 

Software 

Exchange 


Software 

Engineering 

Institute 


Process  Modeling 
Process  Definitions 
User  Interface 
Management 
Configuration 
Managemjnt 


Formal 

Methods 


STARS 


Distributed 

Systems 


Configuration  ^V‘ 

Specif’cason  > 

Integration  into  _ ^ 

SW  process  ^ :ommon 
(  Prototyping 
tv  System 

-  Prototyping  ^ 

-  Reuse 

-  Program  Generation 

-  Module  interconnect 


-  Mach 

-  National  Re 
System 


f  Domain  ^ 
Specific  Software] 
^  Architecture  J 


(  Advanced  \ 

I  Environments  J 

Proofs' Progr^ 
Environment  Architecturo 
User  Interface  Management 
MetriesyMeasurement 


Domain  Specific 
Architectures 
Consensus  Process 
Interface  Validation 


STARS  AND  MEGAPROGRAMMING 

THE  BOTTOM  LINE 


e  Megaprogamming  has  big  potential  payofls 
•  Critical  success  factors  require  a  lot  of  work 


•  STARS  is  committed  to  address  these 


•  Everybody  can  win  by  participating 
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STARS 

VISION,  MISSION,  STRATEGY  AND 
ACHIEVEMENTS 


John  Foreman 
STARS  Program  Manager 
3  December  1991 
p03)  243-8655 
jtf(3)sei.cmu.edu 


VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

OUTLINE 


•  Introduce  STARS 


•  Vision,  Mission,  Strategy 


•  Objectives/Approach 


•  Achievements 


VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

WHY  STARS? 


•  Facilitate  fundamental  changes  in  DoD  software  development 
process/technologies 

•  Address  issues  beyond  the  context  of  any  particular  development 
program* -neutral  ground  to  develop  new  ways  of  doing  business 

•  Influence  commercial  industry  to  accommodate  DoD 
needs/directions 

•  Facilitate  enabling  technologies  for  market  in  DoD  specific  reusable 
components/architectures 

•  Address  DoD  software  problem  sooner 

-  DoD  need  for  application  software  exceeds  available  funding 

-  Current  software  development  paradigm  inefficient 

yitm,  Md  fmmmtJVCS 


VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

STARS  OVERALL  GOALS 
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VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

STARS  VISION  AND  MISSION 


Megaprognunming— An  Emerging  Paradigm 

•  Process-Driven 

•  Doauin-Spcdfic  Reuse-Based 

•  Technology  Supponed 

•  Collaborative  Development  by  Geographically 
Dispersed  Teams 


Accelerate  Megaprogramming 


VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

MEGAPROGRAMMING  SUPPORT 
ELEMENTS 


Procaai  Driven  Devatopment 

•  GaMed  by  a  deiiaed  praeos. 

-  AdepuMe  la  IMM  prsltct/pridaci  fill 

-  Priwaiuii  eoUehimiliia  aad  mmi  »««*. 

•  Sappoewd  by  IMli. 

•  Supports  eontiiluaus  iapraveaaii  ia  process 
aad  predact 

Datasin  Spccilic  Reuse 

•  CuMcd  by  reuse  prectn. 

•  Based  ea  appikatisa  doiaain  architecture. 

•  Systcas  eaaposed  fraa  reusable  assets. 

•  ASMts  laelude  aay/all  lifa  eytie  artiracts. 

«  Supports  contiaueus  iaiproveaMats  ia  reuse 
proccss/products. 

Tecbnotacr  Support 

•  Baaed  upon  epca  architaetnre  frimroarfc. 

•  Adaptabic  approach  far  lacarperadag  or* 
techaoiaglca, 

•  Pachagcd  as  aa  ialt^Hd  Softoare  Eaglaeeriag 

EnriroouMBi  (SEE). 

•  Support  Distributed  Ceaiputiai  sad  nctoork- 
bascd  coilaborativt  devctopsMai. 

•  CoadaiMiu  Impravft  la  partaMliq^  adaptabU* 

icy  rr(iabili(%  and  sealabtllry 

Natorerli-toasad  CoHaborathra  Oavatopmartt 

<  Based  ea  highly  aataakaied  coUaborative 
deveiopmeat  process. 

•  Supports  larfc,  physically  dispersed  traaw, 

•  Provides  tvaaspaieat  access  through  wide  area  lUc 
systcBS. 

•  laciudes  groupware,  structured  eiectroak  reviews, 
eIcctroBic  seeetiags,  etc. 

•  Supports  coBtinaaas  iapreveacat  ia  vwKaortwg 
group  perfonaaBce. 

VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

MEGAPROGRAM^^NG  CONCEPT 


VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

WHAT  PROBLEMS  ARE  WE 
.ADDRESSING? 


Current  Problems 


Lack  of  common  understanding  of 
requirements  between  end* user  and 
developer 


DilTiculty  in  understanding  and 
maintaining  software  developed  by 
others 


Dilllculties  in  scaling  up  to  large 
developments  by  many  people  with 
diversified  skills 


New  systems  often  treated  as 
unprecedented 


Chaotic  and  inefTicient  development 
process 


Megaprogramming  Solution 


Architecture- based  rapid  prototyping 
with  end-user  involvement 


Well-defined  architecture  context, 
component  interfaces  &  localization  of 
behavior 


Megaprogramming  processes  and 
technologies  supporting  architecture 
based  reuse  and  collaborative 
development 


Buildmg  unprecedented  from 
precedented  components 


Defined  processes,  with  continuous 
improvement 
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VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

A  NEW  WAY  OF  DOING  BUSINESS 


•  Software  and  hardware  selection  decisions  will  increase  emphasis  on 
interfaces,  tradeoffs  and  overall  system  engineering  benefit 

•  Contractors  will  invest  in  process  and  reuse  technologies  and 
infrastructure  to  maintain  competitive  edge 

•  Competition  would  be  based  on  integration  of  process,  reuse, 
application  knowledge  and  experience,  and  quality  indicators  as 
opposed  to  cost/LOC 

•  Government  tailors  and  modifies  acquisition  processes  to  reflect  a 
life  cycle  system  view,  as  opposed  to  cost/LOC,  low  bidder,  etc. 

•  Industry  and  government  increase  partnership  across  life  cycle 

-  Increased  end  user  participation 

-  Adopt  ‘product  line”  perspective  within  application  domains 


VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

OUTLINE 


•  Introduce  STARS 


•  Vision,  Mission,  Strategy 

•  Objectives/Approach 

•  Achievements 


VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

TOP  LEVEL  PROGRAM  OBJECTIVES 


•  Demonstrate  the  benefits  of  megaprogramming  in  a  familiar  context 
[create  motivation] 

•  Reduce  megaprogramming  adoption  risks  by  providing  transition 
guidance 

•  Develop  and  accelerate  the  availability  of  processes  and  technologies 
to  support  the  use  and  continued  evolution  of  megaprogramming 


\1SI0N,  MISSION,  STTRATEGY,  ACHIEVEMENTS 

STARS  ACnvmES 


Process 


'^Demonstration^ 


Eittbliih 
jctccoon  and 
success  enuna 
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VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

STARS  APPROACH 


Pouit 

Solutions 


•  Prototypes 

•  Adhoc  solutions 

•  Standalone  capabilities 


Ikchnology 
Evolution 

•  Scalable  solutions 

•  Comtnon  interfaces 
-  Multiple  solutions 

for  SeabUity 

•  Integraboa  with  oth¬ 
er  capabilities 


Cultural 

•  Guidelines 

•  Cost  benefit 

•  Process  and  acqui- 
satiott  changes 

•  Adoptioo  risk  re- 
ducnon 

•  Migraboo  paths 


jlnstituUoml- 
^  -  ^  izatioh  -•?- 


•  Successful  demon- 
strabons  in  real- 
world  context 

•  Significantly  impact 
sate-of-the-prac- 
bce 

•  Conunerdaiizabon 


ITvAliitiAn 


tmnar4 


Z 


Atf/toc 


£xfnff-7bi 


VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

OVERALL  PROGRAM  TIMELINE 

VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

OUTLINE 


•  Introduce  STARS 

•  Vision,  Mission,  Strategy 

•  Objectives/Approach 

•  Acbievements 


mil 


VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

KEY  ACHIEVEMENTS 


Point 

Solutions 


I  niiftitDtiomj*  • 

I  vTtotlon'-'i 


•  2iM  fcacnm 
Itana 

•  Aa0  Ifenry  opes  ardt 

•  lUO  for  r««M  bbnry 
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VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

STARS  FINAL  PRODUCTS 


•  Reuse  processes  and  supporting  tools  including  tailorable  asset  library 
mechanisms 

•  Automated  process  support  and  a  library  of  process  components 

•  Adaptable  ehvironment  solutions  integrating  reuse  and  process 
capabilities 

Integrated  on  or  packaged  within  conforming  commercial  product 
solutions 


VISION,  MISSION,  STRATEGY,  ACHIEVEMENTS 

SUMMARY 


•  Megaprogramming  has  significant  potential  to  reduce  costs  and 
increase  quality  of  large* scale  DoD  software  intensive  systems 

•  Megaprograroming  involves  cultural  change  and  STARS  has  a  strategy 
to  address  this 

•  We  have  interim  products  supporting  the  transition  to 
megaprogramming 

•  Join  us  in  making  this  transition  a  reality 
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ECONOMIC  IMPACT  OF 
STARS  SUPPORTED  TECHNOLOGIES 


Tom  Frazier 
IDA 

(703)  845-2132 
tf razier@fatvax.ida.org 


This  bhefiiis  is  divided  into  four  pam.  The  latroducdoa  reviews  our  cdlabntion  with  Bany  Boehm  on  an 
ecoaomic  analysis  of  DoD  software  cocts.  The  work  ptesented  here  is  a  more  detailed  extension  of  that 
analysis.  The  seeood  port  of  the  briefing  presena  a  descriptioa  of  an  aiwomatrd  model  used  to  analyze  the 
economic  impaa  of  megaprogiaamiing  technologies.  The  third  part  of  the  briefing  details  the  results  from 
^ifriyiiig  this  model  to  four  scenarios.  The  final  part  of  the  tuiefing  presents  a  set  of  conclusions  drawn  from 
our  work. 
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Tom  Frazia,  Brace  Angier  and  Phil  Lurie  «e  Research  Staff  Members  ia  the  Cost  Analysis  and  Raearch 
Divisioa  of  the  Insnmte  for  Defease  Analyses  (IDA).  Betsy  Bailey  is  an  Adjunn  Staff  Member  at  IDA. 
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Tlie  figure  above  was  taken  from  Chapter  10  of  the  Software  Technology  Plan  (SWTP)  and  represents  the 
resulu  of  an  earlier  economic  analysis  that  we  ooUaborated  tm  with  Barry  Boehm.  This  earlier  work  helps  to 
set  the  stage  for  the  presentation  today  which  describes  a  more  detailed  extension  of  that  analysis.  The  top  line 
(Baseline)  repreaetiu  the  projected  growth  in  DoD  software  expenditures  in  the  absence  of  spedfic  DoD 
technology  inveatmenn.  It  assumes  that  the  1992  expenditures  total  S24B  (E1A80,  E1A8S,  EIA90,  AVWX91] 
and  that  the  annual  growth  in  ArmnA  u  4%  [E1A90]  coupled  widt  a  4%  annual  growth  in  productivity  as  a 
result  of  advances  from  die  commercial  sector  in  CASE  technology  [MARTINCT,  LEVTIANSS]. 

The  and  bottom  lines  (Current  and  Achievable)  ate  projections  based  on  two  differont  investment 
In  mtigjpmgrMmmiin  iwrhnnloyiM  The  Current  scenstio  represents  projections  based  oo  the 
cunemly  planned  investmetss  outlined  in  the  SWTP.  The  Achievable  scenario  represents  further  avings  from 
increased  levels  of  investmenL 

One  (rf  tha  goals  stated  for  the  Software  Technology  Plan  is  to  achieve  a  factor  of  two  reductioa  in  software  unit 
costs  by  the  year  2000.  One  of  the  questions  to  be  explored  dirough  the  economic  discussed  here  is 

whether  this  ambitious  goal  can  be  realized. 


SVSTP  COST  SAVINGS  BY  SOURCE 


The  analysis  described  in  the  SWTP  assumes  savings  from  three  sources:  reuse,  process  improvements, 
and  tool:  or  software  engineering  enviroonents  (SEEs).  The  figure  above  shows  the  contribution  of  each 
technology  to  the  savings  found  under  the  Achievable  investment  scenario. 

The  term  ’reuse’  is  intended  to  apply  generally  to  any  form  of  work  avoidance  through  software  reuse, 
applicanon  generators,  and  commercial-off-thC'Shelf  (COTS)  software.  Process  improvements,  which 
include  prototyping  and  risk  management,  enable  projects  to  avoid  costly  rework  and  work  smaner. 
Improvements  in  SEE's  result  in  better,  more  interoperable  tools  which  allow  software  practitioaeis  to 
work  faster. 

In  the  analysis  described  in  the  SWTP.  for  each  of  these  technologies,  there  was  a  time  series  of  parameter 
values  for  each  year  from  1992  to  2008  which  represent  the  fraction  of  savings  (FS)  from  the  use  of  the 
technology  and  the  fraction  of  hme  (FT)  that  the  technology  is  actually  used.  The  realized  savings  for  a 
given  year  were  arrived  at  by  multiplying  the  FS  and  FT  toge±er  and  dien  subtracting  the  prcxiua  from  1 . 
This  value  was  then  multiplied  by  the  baseline  e.spendiaires  to  yield  a  new  projecuon  which  takes  imo 
account  the  savings  resulting  from  the  technology.  For  example,  if  the  FS  for  reuse  in  a  given  year  is 
.70  and  the  FT  is  .10,  then  the  realized  savings  are  (.70)(.10)  »  .07.  Subtracting  fnxn  1  gives  .93  which  is 
then  multiplied  by  the  baseline  costs  to  give  the  new  projected  cost. 


STARS  ECONOMIC  MODEL 


-D'^- 


•  Extends  earlier  model 

•  Includes 

-  Reuse 

-  Process 

-  Tools 

•  Cost  of  these  technologies  reflected  in  labor  rates 

•  Adds  synergy  factor 

•  Incorporates  SEI  Process  Maturity  levels 

•  Maintenance  modeled  as  inventory  flow 

•  Includes  effect  of  quality  (defects/£XOC)  on  maintenance  costs 

CnvoWCamtit  Amtfm  •/  STAJUIr  mmA 
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The  extension  to  the  earlier  model  examines  savings  from  die  same  three  technologies.  It  also  reflects  the  costs 
incuned  in  implementing  these  technologies  via  increased  labor  rates. 

We  felt  that  any  realistic  attempt  to  model  the  economics  associated  with  megaprogramming  must  consider  the 
impaa  of  process  maturity.  The  model  distinguishes  between  the  five  SEI  Process  Maturity  levels.  Though  not 
explicit  in  the  SEI  frameworic,  we  believe  there  is  a  cotrelatioo  between  process  maturity  and  the  level  of 
sophisticahon  of  the  megaprogramming  technolc^es.  Ibis  conelanon  is  reflected  in  the  model  by  assuming 
that,  for  any  given  year,  the  FSs  and  FTs  increase  with  process  maturity  level.  Additioaal  gains  are  realized  at 
higher  levels  through  the  addidon  of  a  factor  to  account  for  synergy  between  technologies.  While  the  SEI  is 
prinmiJy  responsible  for  facilhadng  die  movement  of  software  orgatuzadoas  to  higher  levels,  STARS  it 
expected  to  be  a  facilitator  as  well  by  enhancing  the  technologies  which  underlie  this  movement.  The  analysis 
is  conservative  in  that  STARS  is  not  given  any  credit  for  this  fadlitadoa 

A  pordon  of  the  model  deals  with  development  costs  and  a  pordon  with  nuuntenanoe.  Maintenance  is  modeled 
as  an  inventory  flow  process  and  will  be  described  in  more  demil  in  a  later  vugrapb. 

The  model  a«iiTTii«x  that  quality  increases  with  increases  in  SEI  level.  Variarjons  in  code  quality 
(defects/KLOC)  affect  the  atnrum  of  conrecdve  maintenance  required  in  the  model  and  are  reflected  in 
cOStt. 


I 


36 


SCENARIOS  EXAMINED 


•  Megaprograinniing  Baseline 

•  STARS  Value  Added 

•  Further  Acceleration  of  Megaprogramming 

•  2X  Reduction  Goa! 


%tyt0urCMUtmut  AaalTtti  tl  STAMSIlniittH 


Hie  resuhs  of  modeling  several  difTerem  scenarios  will  be  described.  The  scenarios  are  listed  above. 
scenario  will  be  discussed  in  deoil  in  later  vugr^ihs. 

The  Megaprogramming  Baseline  reflects  our  best  estimate  of  the  rate  at  which  the  FS  and  FT  aw^atH  with 
reuse,  process,  and  S££s  will  change  over  tiine.  Several  snidies  have  shown  that  the  adopcon  of  new 
technologies  is  extremely  slow.  Studies  by  IDA  have  shown  that,  on  avaage,  it  eilc«  9  years  between  the 
introduction  of  a  technology  until  it  is  used  S0%  of  the  time  (FT  >  .SO)  and  18  yean  until  its  use  approaches 
100%.  The  STARS  Added  Value  scenario  reflects  changes  to  the  FTs  and  FSs  to  teflea  acceleration  in  the 
adoption  of  these  technologies  and  greater  savings  from  their  use.  The  Further  Acceloatioo  of 
Me^progratnming  scenario  looks  at  the  impact  of  moving  the  adoption  of  these  technologies  up  even  faster 
than  the  rate  we  envision  with  STARS.  Finally,  the  2X  reduction  scenario  looks  at  one  combination  of  model 
parameters  which  do  produce  the  stated  goal  outlined  in  the  Software  Technology  Plan  of  reducing  software 
unit  costs  by  a  factor  of  two.  The  feasibility  of  meeting  these  parameter  values  will  be  discussed. 

For  each  of  the  scenanos,  the  bottom  line  values  of  interest  are  the  total  DoD  software  costs  for  each  year 
included  in  the  scenaric  and  the  Net  Present  Value  of  savings  in  the  future.  The  latter  discounts  future  constam 
dollar  savings  by  10%  per  year  and,  as  such,  represents  a  conservanve  measure  of  the  economic  value  of 
megaprogramming  technologies. 

Prior  to  presenring  the  scenarios,  the  basic  structure  of  the  model  is  briefly  described. 
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The  model  contaus  a  developmem  and  a  mauaeoance  ponion.  Code  developed  in  a  given  year  is  and 
tracked  through  the  maintenance  portioa  of  the  model.  Both  new  code  and  maintained  code  is  tracked  by  year 
and  by  SEI  capability  level 

The  model  is  implemented  as  an  Excel™  spreadsheet  containing  approximately  40.000  cells.  It  requires  about 
1.2MB  of  disk  space. 


™Excei  is  a  registered  trademark  of  Microsoft  Corporation. 
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NEW  DEVELOPMENT  PORTION 
OF  MODEL 


-IMRDV: 


PMs  a(KDSl)^  *  Reuse  *  Process  ♦  Tools  *  Synergy 


Reuse  = 
Process  = 
Tools  = 
Synergy  = 


1  •  (FT  ♦  FS) 

1  -  (FT  *  FS) 

1  -  (FT  *  FS) 
f  (Process,  Tools) 


SEI  Level  5 


S£1  Level  2 


SEI  Level  1 

Year 

EE  ES 

1992 

.09  .50 

1993 

.11  .51 

2008 

JO  .60 

K>?aaWt<MMic  Anatnii  af  STAJtSTnnini* 


Tbe  smicture  of  ihe  Development  portion  of  die  model  is  shown  above.  A  COCOMO>likB  equation  is  used  to 
calculaie  effort  and  costs.  Effon  calculations  are  made  for  each  SEI  level  for  each  year  frcm  1992  through 
2008. 

The  alpha  and  beta  terms  vary  aaoss  SEI  levels  as  shown  below.  These  coefTiciems  generate  software 
development  productivities  consistent  with  those  reported  in  [PUTNAM9I]. 
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The  Reuse,  Process,  and  Tool  factors  in  the  equation  represent  the  produa  of  FS  and  FS  which  is  subtracted 
from  1.  These  operate  as  do  the  Effon  Adjustment  Factors  (EAFs)  in  CCXTOMO.  The  contribution  of  each  of 
the  three  factors  can  be  furtha  enhanced  via  the  Synergy  faao.'  which  is  set  to  1  for  SEI  Levels  1  and  2  and 
less  than  1  for  Levels  3, 4,  and  5. 


Tbe  incorporanoo  of  new  technologies  is  represented  by  the  FT  pamneters  in  the  model.  As  descnbed  evUer, 
these  psnsneten  represea  the  firactiaa  ol  software  that  is  being  developed  using  the  megaptogtitanring 
technologies.  The  values  of  these  parameien  are  key  demnninants  of  the  dollar  savings  using  the 

The  figure  above  shows  two  ways  that  the  FT  parameters  could  be  modeled.  The  straight  line  shows  a  fixed 
increase  every  year.  While  this  is  the  simplest  way  to  model  changes  in  FT  over  time,  it  may  not  accurately 
reflect  the  path  by  which  some  technologies  come  into  use.  For  example,  software  reuse  may  be  associated 
with  a  suhstantial  overhead  at  first  as  software  libraries  are  developed  and  populated  with  components.  This 
would  result  in  a  slow  increase  in  the  early  years  followed  by  an  acoeleranoo  as  libraries  become  more  fully 
populated  and  finally  a  flattening  out  as  projects  reach  a  ceiling  in  terms  of  the  proportioa  of  software  that  can 
be  developed  from  reusable  componemt.  This  technology  transitiae  path  is  represented  by  the  S-sbaped 
curve  in  the  figure.  In  the  model,  the  FTs  are  Linear  across  time  for  process  and  SEEs  and  S-shaped  for  reuse. 
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The  Maizaeoance  partioo  is  tDOdclod  as  an  itrventoo' flow  process.  Maimenancc  begias  wiih  a  swck  of  existing 
code  to  be  maimaincd.  Each  year,  newly  developed  code  is  added  to  the  total  stock  of  coat.  Soaie 

code  is  deleted  from  the  total  stock  via  obsolescence  and  some  is  reengineered.  A  pothon  of  the  stock  of 
m«inf«in#iri  code  is  changed  as  a  result  of  corrective,  adaptive,  and  perfective  maintenanoe.  Varianons  is  code 
quality  (defects/KLOQ  affea  the  amount  of  corrective  maintenance  and  are  reflected  in  tn«im^aivy  costs. 

The  model  assumes  different  defea  densities  and  different  maintenance  producdvines  for  diffaets  S£I  levels. 
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MEGAPROGRAMMING  BASELINE 


•  Reflects  technology  savings  (FSs)  and  technology  use  (FTs) 
without  STARS 


•  FSs  and  FTs  increase  over  time  and  across  SEI  levels 


•  Distribution  of  firms  across  SEI  Levels 
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•  1992  SEI  distribution  from  SEI  assessments 


AnM*  If  STAUFndbM«II 


The  firg  icemrio  rqpreMna  the  MqtiproKiiinining  Baseline.  This  sceaario  refleca  our  best  estimates  of  the 
saviogs  (FSs)  resulting  from  megaprognmming  tedunlogies  and  the  fraciioo  of  tisoe  (FT)  they  are  likely  to  be 
used  in  the  absence  of  STARS-related  efTara  to  acoelerete  these  technologies. 

The  disthbutioo  of  projects  across  SEI  levels  is  shown  above.  The  starting  values  were  taken  from  the  results  of 
the  most  recent  SEI  assessmenu  [KTTSON^  1  ].  The  disthbution  changes  annually  with  fewer  projects  in 
Level  1  over  time  and  a  greater  proportioa  at  die  higher  levels.  The  movement  across  levels  represents  our 
best  bssed  on  work  by  [FUTNAM911.  (The  SEI  currently  has  no  such  projections.) 

In  the  Megaprogramming  Baseline,  the  FS  .jxl  FT  .-alues  increase  gradual]/  o^-~r  time  and  as  one  moves  up  the 
SEI  levels. 
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The  estimated  total  annual  DoD  toftwate  costs  for  the  Megaprogranuning  scenario  is  presented  is  the  chan  shown 
above.  We  estimate  by  the  year  2000.  this  scenario  will  restih  in  annual  cosu  cf  about  S3S  billion  in  then-year 
dollars.  The  lesula  ate  presented  in  billions  of  then-year  dollars.  In  constam  1992  dollars,  the  ««■-»«!  costs  estitnaies 
remain  fairly  constant  around  S24  billion  over  die  19^-2000  time  period. 
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STARS  VALUE  ADDED 


•  Distribution  across  S£1  levels  identical  to  Megaprogrammlng  Baseline 
(conservative  assumption) 

•  Higher  FSs  and  FTs 

•  5  %  average  difference  for  FSs 

•  15%  average  difference  for  FTs 


•  Example  with  FTs  for  External  Reuse 
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STARS 
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•10%  more  code  can  be  maintained  per  person  year 


it  A— lyiii  STj^RS/TmtrfO 


The  disaribution  of  projects  sooss  SEl  Irvds  is  the  seme  for  the  SfARS  Value-Added  scextario  as  for  the 
Megaprogramming  Baseline.  While  the  fas  and  FTs  begin  with  identical  values  for  the  fim  year  (1992), 
the  rate  of  increase  is  higher  for  the  STARS  Value-Added  scenario  with  the  result  that,  on  average,  the  FS 
values  are  approaitratcly  5*  higher  than  for  the  Megaprogrammiag  Baseline  while  rfae  FT  values  are 
approximately  13%  higher. 

One  additional  difference  between  the  two  scenarios  is  a  10%  increase  for  the  STARS  Value  Added  in  the 
amoiiiB  of  code  that  can  be  maintaineo  per  person  person  year. 


Tliis  cbsT  pracBU  the  estimated  additioaal  savings  DoD  might  realize  due  to  the  STARS  program.  Again,  the 

estimates  are  presented  ia  billions  of  theifyear  dollars.  If  we  compute  the  value  of  the  savings  in  today's  dollars  and 

also  for  the  time  value  of  moot.'y  by  "discounting*  the  stream  of  savings,  the  result  is  a  finandal  measure  of  , 

merit  called  the  Net  Presem  Value  (NPV).  The  Office  cf  Managemem  and  Budget  (0MB)  guidelines  specify  a 

discooffl  rate  of  10%.  This  rate  was  used  in  all  the  reported  NPV  results.  The  NPV  of  the  additional  STARS 

savings  is  estimated  to  be  $6.6  billioa 

This  is  a  conservative  estimate  of  the  potential  savings  from  the  STARS  program  for  two  reasons.  First,  many  of 
the  savings  will  only  be  realized  in  the  first  decade  of  the  neat  century.  For  purposes  of  this  study  we  ignore  those 
savings.  Second,  we  assume  it  will  take  sotrx  time  for  the  full  eoent  of  the  payoff  from  STARS  technology 
infusioa.  Given  OMB's  10%  discount  rate,  savings  that  occur  in  the  out-years  are  rather  severely  discounted. 

« 
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FURTHER  ACCELERATION  OF 
MEGAFROGRAMMING  (BY  1  YEAR) 


•  FTs  and  SEI  level  distributions  moved  from  2001  to  2000 

•  intbnnediate  values  interpolated 
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ic  AnMi  if  STARS/Fndnf  IS 


The  next  soenario  looks  at  the  effects  cf  accekmiag  technology  tnasiDon  by  ooe  year.  TheSTARS  Value 
Added  scenario  was  chosen  at  the  baselirse  for  this  analysis.  The  distribution  of  finm  across  SQ  levels  in 
the  year  2001  was  assigned  to  the  year  2000.  In  additioo.  the  FTs  frtan  the  year  2001  were  assigned  to  the  year 
2000.  Values  between  1992  and  2000  were  interpolated. 
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FURTHER  ACCELERATION  OF 
MEGAPROGRAMMING  (BY  2  YEARS) 


FTs  and  SEI  level  distributions  moved  from  2002  to  2000 
Intermediate  values  interpolated 
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Tliis  scetmio  looked  at  the  effects  of  accelerating  technology  transition  by  nvo  years.  The  STARS  Value 
Added  scenario  was  again  chosen  as  the  baseline  for  this  analysis.  The  distribution  of  finns  across  SEI  levels  in 
the  year  2002  was  to  the  year  2000.  In  addition,  the  FTs  from  the  year  2002  were  assigned  to  the  year 

2000.  Values  between  1992  and  ^XI2  were  interpolated. 
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FURTHER  ACCELERATION  OF 
MEGAPROGRAMMING:  RESULTS 
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The  chm  thowt  the  esdtaaLsd  iddihosal  uviags  resohisg  from  »ccel<nting  pace  of  techaology  txamitioa 

asstuxted  ia  the  STARS  sceaaorio  by  both  one  and  two  yean.  The  NPV  of  these  actional  savings  for  one  year 
acceloanon  is  caomased  to  be  S4,l  billion.  The  N*PV  of  die  iacremenal  savings  gained  by  speediag  up  software 
techaology  utiluation  by  two  yean  is  esriwated  to  be  S2.4  billion.  The  total  NPV  of  the  conibined  savings  due  to  the 
acceleranoa  of  new  technologies  is  billion,  or  about  equal  to  the  estimated  savings  due  to  STARS. 
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As  noted  earlier,  one  at  the  goals  of  the  Software  Technology  Plan  is  to  reduce  DoD  software  costs  by  a  faaor 
of  two  by  the  year  2000.  We  tried  various  combinations  of  savings  generated  by  STARS  and  savings  geiwaieo 
by  moving  ftrtns  up  SEI  levels  in  order  to  ascertain  if  such  a  reduction  was  possible.  Using  the  Megaprogramming 
Baseline  expenditures  of  S24B  (in  constant  1992  dollars)  for  the  year  2000,  we  found  a  combination  of  savings  from 
STARS  plus  savings  from  moving  hmis  across  SEI  levels  that  will  result  in  exprenditures  of  S12B  in  the  year  2000. 


Note  that  currently,  8046  of  software  firms  are  in  Level  1.  This  value  has  to  decrease  to  5%  in  Just  eight  years 
to  realize  the  2X  reduction  goal.  Is  it  possible  to  move  from  80%  of  the  firm',  in  Level  1  to  only  S%  by  the  year 
2000?  It  seems  unlikely.  However,  without  programs  such  as  STARS  it  is  virtually  impiossible. 


The  resulu  of  ;fae  fitaJ  iceoaho  art  presented  graphically  above.  The  esri mated  NPV  of  the  addiiioaal  savings  from 
this  scenario  is  SlS.l  billioa 


CONCLUSIONS 
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•  Small  percentage  changes  in  model  parameters  have  large  dollar 
impacts 

•  To  the  extent  that  STARS  can  effect  these  changes,  it  will  have  an 
enormous  payoff 

•  Large  savings  can  be  captured  by  simply  advancing  technology 
improvement  by  one  year 

•  Reducing  DoD  software  costs  by  a  factor  of  two  by  the  year  2000 
will  be  very  difficult  to  achieve 
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This  research  is  on-going  ssd,  therefore,  any  conclusions  we  might  draw  about  the  particular  dollar  savings 
must  be  viewed  as  tentative.  However,  there  are  several  conciusioos  that  can  be  put  forward. 

Fu^  the  model  is  very  sensitive  to  small  changes  in  several  key  parameters.  These  include  the  distribution  of 
firms  across  SEI  levels,  the  values  of  FT,  especially  in  the  early  years  before  their  impaa  is  dampciKd  by 
discounnng.  and  the  amount  of  code  that  can  be  maimained  by  one  perion  per  year. 

Second,  to  the  extent  that  the  STARS  program  can  effea  these  changes,  it  win  have  a  reladvely  large  payoff. 
Even  tf  the  estimated  discounted  savings  are  cut  in  half,  STARS  is  still  extremely  cost  effective. 

Third,  the  model  suggests  that  a  small  acceleration  in  the  introduction  of  new  software  technologies  has  a  large 
payoff. 

Finally,  achieving  the  goal  of  reducing  total  DoD  software  cosu  by  the  year  2000  will  require  significam 
loprovemems  in  the  way  DoO  develops  and  maictains  software. 


» 


REFERENCES 


I 


[AVWK90] 
[BASIU  81] 

fB0EHM81] 
[BOEHM  89] 
[BOEHM91a] 

[BOEHM91b] 

[EIABO] 

[EIA85] 

[E1A90] 

[EIA91] 

[HELIJER90] 

rHUMPHREY89] 

(JONES  86] 
[KITSON91] 

[LEVTTANSS] 

[MARnN83] 


Aviadoti  Week  Sl  Space  Technology,  March  18,  1991,  Vol.  134,  No.  11,  p. 
51. 

Basili,  VJL.  and  Frcburger,  K.,  *Piogranumng  Measurement  and  Estimation  in 
the  Software  Engineering  L^ratory,*  Journal  of  Systems  and  Software, 
Fcbniaiy  1981. 

Boehm,  Barry  W.,  Software  Engineering  Economics,  Prentice  Hall,  Englewood, 
NI,  1981. 

Boehm,  B.W.,  and  Royce,  W£.,  *Ada  COCOMO,"  Proceedings  Fourth 
COCOMO  Usm*  Group  Meeting.  SEI,  November  1989. 

Boehm,  B.W.,  *Economic  Aitalysis  of  Software  Techno?  '>gy  Investments,”  April 
29,  1991,  bnefing  chans  presented  at  Mitre  Software  Engineering  Economics 
Omference,  April  29, 1991. 

Boehm,  B.W.,  Frazier.  TJ*.,  Angier,  B.,  Bailey.  EJL,  and  Wilson.  KX.,  A 
User's  Guide  For  The  Software  Technology  Economic  Impact  Model,  Institute 
for  Defense  Analyses,  IDA  Document  D-971,  October  1991. 

*DoD  Digital  Data  Processbg  Snidy:  A  Ten  Year  Forecast,”  Dectronic 
Industries  Association,  mimeogiaphed  annotated  bheEng. 

*DoD  Computing  Activities  and  Picgtams,  1985  Specific  Market  Study,” 
Retjoirements  Committee.  Government  Division,  Electronic  Industries 
Associanoo,  mimeographed  annotated  briefing. 

EIA  Information  System  Forecast  for  the  1990's:  the  2nd  Annual  Federal 
JnformatioH  Systems  Cotference  Final  Report,  Requirements  Committee, 
Govenunent  Division.  Electronics  Industry  Association,  May  30,  1990, 
Alexandria,  VA 

EIA  Information  System  Forecast  for  the  1990's:  the  3rd  Annual  Federal 
Information  Systems  Conference  Final  Report,  Requirements  Committee, 
Government  Division,  Electronics  Industry  Association,  May  23.  1991, 
Alexandria.  VA 

Heller,  Gerald  H.  and  Page,  Gerald  T.,  ”Impact  of  a  Process  Improvement 
Program  in  a  Production  Software  Environroenc  Are  We  any  Better?”, 
Proceedings  of  the  Ffteenth  Annual  Software  Engineering  Workshop,  (SEL-90- 
006,  NASA  Software  Engineering  Labotatoty,  Goddard  Space  Flight  Center. 
November  1990, 

Humphrey.  W.  S..  Kitson,  D.  H..  and  Kasse,  T.  C.,  The  State  of  Software 
Engineering  Practice:  A  Preliminary  Report,  CMU/SE1-89-TR- 1  or  ESD-TR-89- 
01,  Software  Engineering  Instiiute,  February,  1989. 

Jooes,  T.C..  Programming  Productivity,  McCmv  Hill,  1986. 

Kitson,  David  and  Masters.  Stephen,  ’State  of  the  Practice:  A  Software  Process 
Maturity  Prospective’,  (tnimeo).  Software  Engineering  Institute,  August  1991. 

Levitan,  K.  B.,  Salasin,  J..  Frazier,  T.  P.,  and  Angier,  B.  N.,  Fmal  Report  on 
the  Status  of  Software  Obsolescence  in  tte  DoD,  IDA  Paper  P-2136,  Institute 
for  Defense  Analyses,  August  1988. 

Martin,  E.,  The  Context  of  STARS Computer,  Vol.  16,  No.  3,  March  1983, 
p.  14-17. 


52 


[OMB72] 

[PUTNAM91] 

[RATIONAL89] 

[REIFER90] 

[SnDOWlTZ89] 


[SHAFER91] 

[S'WTP91] 

[WimS90] 


Office  of  Management  and  Budget,  "Discount  Rates  to  be  Used  in  Evaluating 
Time-Disnibuted  Costs  and  Ben^ts",  Circular  No.  A-94,  »iarch  27. 1972. 

Putnam,  L.  H..  "Linking  the  QSM  Productivity  Index  with  the  SEI  Maturity 
Levels  and  Projecting  Transitions  to  Various  Maniriiy  Levels’,  ©  1991,  QSM. 
McLean.  Va. 

Mimeographed  Rational  Corp..  dated  December  1989. 

Reifer,  D.,  "Reuse  Metrics  and  Measurements’,  Proceedings  of  the  Fifteenth 
Annual  Software  Engineering  Workshop,  (SEL-90-006,  NASA  Software 
Engineering  Laboratory,  Goddard  Space  Flight  Center,  November  1990. 

Seidowitz,  £.  airi  Stark.  M.,  "Ada  in  the  SEL:  Experience  with  Oper  iooal  Ada 
Projects,"  Proceedings  of  the  Second  NASA  Ada  Users'  Symposium,  SEL-89- 
008,  NASA/SEL,  Goddard  Space  Flight  Center,  Greenbdt,  MD,  November, 
1989. 

Constructed  from  hourily  labor  rates  obtained  from  William  Shafer,  IDA. 

Department  of  Defense  Software  Technology  Plan,  Volume  11;  Plan  of  Action, 
Prepared  for  Director  of  Defense  Research  and  Engineering,  Draft  6,  October  3 1 , 
1991 

Willis,  Ronald  R.,  "Case  History  and  Lessons  Learned  in  Software  Process 
Improvement",  Mimeo,  April  1990. 


Parameter  Type 

Source 

DuD  Software  Spending 

EIA(alD,AVWK91 

Discount  Rate 

OMB72 

SEI  Distributioos  (starting) 

HUMPHREY89.  K1TSON91 

COCOMO  patameteR  and 
productivity  start  values 

Fit  to  material  cited  in  PUTNAM90, 
alsoBOEHMS9 

Ptoducovity  Growth 

MARTIN83.  LEVTTANSS 

Reuse 

FT 

SWTP91 

FS 

SEIDOWrrZ89,  RE1FER90.  BASILI81 

TooU 

FT 

SWTP91 

FS 

SWTP91.RATIONA’ 

Process 

SWTP91,  JONES86 

General  .Maimenance 

BOEHMS  1.  HELLER90,  PUTNAM91 

Labor  Rates 

SHAFER91.  W1UJS90 

53 


NOTES 


55 


NOTES 


S6 


TECHNOLOGY  TRANSITION 
AND  COMMUNITY  INVOLVEMENT 
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jtf@se).c;nu.edu 


TRANSITION  AND  COMMUNITY  INVOLVEMENT 

BRIEFING  PURPOSE 


Ducuss  STARS  technology  transition  (TT)  activities/plan 
Identify  community  participation  opportunities 


TRANSITION  AND  COMMWTTY  INVOLVEMENT 

WORKING  TOGETHER  TOWARDS 
MEGAPROGRAMMING 


^  TO*! 


UMge 

•  Work  together  to  evolve  point  solutions  to  meet  broad  cultural  and 
organizational  needs 

•  THal  usage  needed  to  evolve  Megaprogramming  processes  and 
technologies 

•  Suppliers  and  customers  need  to  work  together  to  better  understand 
and  overcome  the  cultural  impact  and  barriers  to  acceptance 
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TRANSITION  AND  COMMUNITY  INVOLVEMENT 

CULTURE  CHANGE  ISSUES 


Culture  changes  requires  community  involvement 

The  changes  will  require  us  to  work  together  to: 

•  Create  a  clear  vision  of  Megaprogramming 

•  Gain  insights  into  cost  and  benefits  of  Megaprogramming 

•  Develop,  test  and  demonstrate  the  processes  and  technologies 
necessary  to  support  Megaprogramming 

-  Identify  and  validate  migration  paths 

•  Identify  and  reduce  barriers  and  risks  to  adoption 


TRANSITION  AND  COMMUNITY  INVOLVEMENT 

OUTLINE 


•  Megaprogramming  and 
Culture  Change 

•  Community  Involvement 

•  AfTiliates  Program 


t/yo4 


TRANSITION  AND  COMMUNITY  INVOLVEMENT 

RECENT  COMMUNITY  INVOLVEMENT(i) 


•  Infokination  Dissemination 

-  STARS  quarterly  newsletters 

-  TRI-Ada  90  and  91  booths 

-  STARS  brochure 
•  STARS  catalog 

-  Technical  papers/presentations 

-  STARS  Users  Workshop  (Sep  90) 

•  Provide  neutral  ground  to  foster  community  consensus/convergence 

-  Framework  convergence  meeting  (Jan  91) 

-  CASE  Vendors  Workshop  (July  91) 

-  ASIS  Working  Group  (July,  Oct  91) 


TRANSITION  AND  COMMUNITY  INVOLVEMENT 

RECENT  COMMUNITY  INVOLVEMENT(2) 


Work  within  community  to  establish  megaprogramming  infrastructure 
•  Instrumental  in  establishing  RIG 

-  Initiated  SEI/STAKS  Process  Asset  Library  development 

-  Established  ASSET  to  facilitate  electronic  distribution  of  community 
megaprogramming  products 
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TRANSITION  AN*D  COMMUNITY  INVOLVEMENT 

CONTEXT  FOR  AFFILIATES  PROGRAM 


umm 


•  STARS  technology  transition  coordinator 

•  Packaging  of  interim  products 

•  ASSET:  Asset  Source  for  Software  Engineering  Technology 

•  Commercialization 

•  Demonstration  projects 


TRANSITION  AND  COMMUNITY  INVOLVEMENT 

STARS  AFFILIATES  PROGRAM  OVERVIEW 


STARS  Information  Affiliates 
•  General  community  information  dissemination 

STARS  Technology  Transfer  AflUiates 

-  Commitment  of  effort  (STARS  and  Afllliates) 

STARS  Prime  Affiliates 

-  Case-by-case  basis  between  /Vffiliates  and  STARS 
prime(s) 
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TRANSITION  AND  COMMUNITY  INVOLVEMENT 

INFORMATICN  AFFILIATE 


•  How  do  you  get  information 

-  STARS  newsletter,  conferences,  STARS  mailing  list 

-  Monthly  briefings  and  demonstrations  at  STARS  Technology  Center 
(Start  1Q92) 

•  STARS  bulletin  board 

•  How  do  you  get  products 

•  Publicly  released  products  described  in  STARS  Catalog 

-  Hardcopy  through  DTIC  and  NTIS 

•  Electronic  distribution  through  ASSin' 

•  Cost 

-  Minimal,  time  to  read  and  evaluate 

•  How  to  sign  up 

-  Fill  out  Information  Afliliatc  form  in  your  package 


TRANSITION  ANT)  COMMUNITY  INVOLVEMENT 

TECHNOLOGY  TRANSFER  (TT) 
AFFILIATES  (d 


•  How  do  you  get  information 

-  You  will  be  provided  an  account  on  ASSET  upon  request 

-  Mailers,  news  groups  on  ASSET, . . . 

-  Technology  exchange  working  groups 

•  How  do  you  get  products 

-  AFS  account  on  ASSET  for  access  to  internal  STARS  work  products 

•  Cost: 

-  Your  organization  committing  a  specific  individual 

-  Staying  up  to  date  on  STARS  activities 

-  Participating  in  reviews  and/or  evaluations 
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TRANSITION  ANT)  COMMUNITY  INVOLVEMENT 

TECHxNOLOGY  TRANSFER  (TT) 
AFFILIATES 


•  How  do  you  provide  feedback 

-  Providing  review  and  feedback  on  STARS  work  products 

-  Conducting  alpha/beta  test  of  products  and  providing  lessons  learned 

-  Paiiicipatirg  in  joint  technology  experiments 

-  Participating  in  TT  Affiliates  mee'mgs 

-  Future  STARS  Conferences  become  TT/Prime  Affiliates  Users 
meetings 


TRANSITION  ANT)  COMMUNITY  INVOLVEMENT 

TECHNOLOGY  TRANSFER  (TT) 
AFFILIATES  o) 


•  2  way  technology  transition 

-  Broaden  exposure  for  your  technology  to  technically  knowledgeable 
community 

-  Publicize  your  products  supporting  inegaprogramming  in  .ASSET 

-  Potential  use  of  your  domain  specific  assets  on  a  demonstration  project 

•  How  to  sign  up 

-  Number  of  TT  Affiliates  Limited 

-  Participate  in  appropriate  technology  area  sessions  this  evening 

-  Submit  TT  Affiliates  questionnaire  and  information  forms 
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TRANSITION  AND  COMMUNITY  IN'VOLVEMENT 

STARS  PRIME  AFFILIATES 


•  Approach:  extended  TT  afliliate  that  also  works  directly  with  STARS 
prime(s).  Examples: 

-  Co-development  of  SW  engineering  capabilities 
•  Joint  commercialization  effort 

-  Prime  may  pro>ide  access  to  SEE  testbeds  for  selected  integration 
experiments 

•  How  to  sign  up 

-  Negotiation  with  individual  STARS  primes  on  a  case -by -case  basis 

-  Contact  Boeing,  Unisys,  IBM,  program  managers 


TRANSITION  AND  COMMUNITY  INVOLVEMENT 

JOIN  US  IN  TRANSITION  TO 
MEGAPROGRAMMING 
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TRANSITION  AND  COMMUNITi'  INVOLVEMENT 

TECHNOLOGY  TRANSITION  APPROACH 
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THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND 

STARS 


Barry  Boehm 
DARPA 
STARS  91 
4  December  1991 
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THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

OUTLINE 


•  Software  Technology  Plan  (SWTP)  Overview 

•  Relation  to  Software  Action  Plan  (SWAP) 

•  Why  will  the  SWTP  make  a  difference? 

-  Driven  by  user  needs 

-  Focused  on  high -leverage  strategies 

-  Integrated  across  technology  and  management 

-  Developed  by  its  responsible  implementors 

-  Focused  on  technology  transition  to  customers 

•  STARS  support  of  SWTP 

•  SWTP  participation  opportunities 


THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  TARS 

OVERVIEW  OF  DOD  SOFTWAR^ 
TECHNOLOGY  PLAN 


•  Part  of  DDR&E  Software  Action  Plan 

•  Scope  includes  all  DoO  software  technology  base,  FY  1992-2007 

-  6.1,  6.2,  6.3A  Software  Science  and  Technology  Programs 

•  Being  created  by  DoD  software  technology  program  managers 

-  With  extensive  external  review  cycle 

•  IVvo  investment  program  levels  defined 

-  Current  program:  Hat  out-year  budgets 

-  Achievable  program:  increase  to  cover  technology  opportunities 

•  ROI  analysis  performed  to  determine  whether  investment  justified 


THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

SWAP  CONTEXT 


•  Software  is  key  to  smart,  flexible  DoD  forces 

-  Desert  Storm:  PGM’s,  Patriot,  surveillance,  logistics 

•  Software  is  diiTicult  to  acquire  and  support 

-  USAF/ESD:  70%  of  problem  projects  due  to  software 

•  Software  cost  increasing  from  current  $24-32B/year  level 
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THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

SWAP  OBJECTIVES 


By  year  2000: 

•  Reduce  equivalent  software  life-cycle  costs  by  a  factor  of  2 

•  Reduce  software  problem  rates  by  a  factor  of  10 

-  Acquisition:  problem -project  rate 

-  Operations:  software  failure  rates 

•  New  levels  of  mission  capability,  interoperability 
~  Global  surveillance  and  communications 

-  Precision  strike 

-  Steaith/counter- stealth 

-  Undersea  superiority 

-  Superior  ground  combat  vehicles 

-  Thiining,  readiness  and  simulation 

-  Technology  for  affordability 
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THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

SWAP  APPROACH 


1.  Bring  software  process  under  management  control 

2.  Integrate  controllability  and  efficiency  '.la  technology 
-  While  expanding  mission  functionality 


3.  Concurrently  pursue  other  enabling  actions 

-  Personnel,  education,  data  rights,  policies  and  sUndards 

4.  Effect  closed -loop  continuous  process  improvement 

-  Via  integrated  management  and  technology  program 


DmO  TtAjOiM 
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THE  DOD  SOFTWARE  TECHNOLOGY  PLAf'I  AND  STARS 

SWAP  CAPABILITY  GOALS  AND  1  f  DA 
INITIATIVES 


CAPABILITY  GOALS 

CURRENT  INITIATIVES 

•  Modern,  intesrated  systeiB/life-cycle  process 

•  DoD-STD-2167A,  793SA  upgrades 

•  Reinforced  by  strong  management  assessment 

•  DAB  software  expert  reviewers 

capabilities 

•  S£1  SW  maturity  assessments 

•  Reinforced  by  cost-effective  software 

•  DoD  Software  'I>chnology  Plan 

technology 

•  Open  system  standards 

•  Performed  by  capable,  mature,  DoD  contractor 

•  SEl  SW  maturity  assessments 

organizations  and  people 

•  SW  personnel,  education  initiatives 

•  Quantitative  improvement  via  instrumentation 

•  Core  SW  metric  standards 

and  analysis 

•  SW  in  MlL-STD-«81B(WrS) 

DtC  swr^  md  TTaKiM  dddmdVCt 

THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

OUTLINE 


•  Software  Technology  Plan  (SWTP)  Overview 

•  Relation  to  SWAP 

•  Why  will  the  SWTP  make  a  dilTerence? 

^  -  Driven  by  user  needs 

-  Focused  on  high-leverage  strategies 

-  Integrated  across  technology  and  management 

-  Developed  by  its  responsible  implementors 

-  Focused  on  technology  transition  to  customers 

•  STARS  support  of  SWTP 

•  SWTP  participation  opportunities 
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THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

THE  SWTP  IS  DRIVEN  BY  USER  NEEDS 


•  Initiated  by  analysis  of  service  needs  documents 


•  Integrated  with  DoD  S&T  strategic  framework 


•  Iterated  with  user  community 

•  Involves  users  in  technology  development 


THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

EXAMPLE  OF  NEEDS  AND  CAPABILITIES 


C3I  Function  Needed 

Needed  Software  Capability 

Current  Software  Capability 

Evaluate  threat  situation  and 
available  options,  particularly  tor 
complex,  deceptive,  adversary 
situations 

•  Dedsion-oriented  information 
presentation 

•  Only  for  relatively  simple 
decision  situations 

•  Smooth  hypermedia 
in'ormalion  structure 
navigatioa 

•  Fragile,  moderate-scale  initial 
capabilities 

•  Rapid  prototyping 

•  Good  for  graphic  user 
interfaces;  limited  for 
information  navigation 

•  Scalab’e.  integrated  database 
and  knowledge-base 
capabilities 

•  Some  initial  medium-sode  to 
targc-ecate  capabilities 
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THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

DOD  SOFTWARE  TECHNOLOGY 
NEED  AREAS 


Global  Thaataf. 
Porea.  Group  C3I 

•  0«Mct 

•  Fuaa 
>Evaiu*t« 

•  Plan 
•Dodd* 

•  Ordar 

•  EaactiM 

•  Man«g« 

•  TranamH  IitIo 

•  0«ny  Info 


CombaUlnit*^ 

•  Unmannod 
Platform/ 

Vahicia  Control 

•  Mannad  Platform/ 
Vabicla  Control 

•  Sanaora  artd 
SurvaiUanca 

•  Tactical  Oadtion 
Support 

•  Intra-  k  Intar-Unit 
Communicationa 

•  Waaporw  Control  & 
Daploymartt 


'  Attributaa 


•  Raconfigurabla 
Manufg,  •  Intaroparabla 
Sciartca  •  Portabla 

k  Engr  •  Usabla 
Simulation  •Dialributad 
•Parallel 

4  Training 

•  Robuat 

•  Secure 

•  Safa 


|C1M_ 

•  Finance 

•  Logiatica 

•  Medical 

•  Peraonnai 


- - 

Fundona  Attributes 


•  Process 
Tailoring 

•  Prototyping 

•  Rqt^  Engr. 

•  Design 

•  Oavciopmant 

•  Qualification 

•  Lifa-Cycla 
Support 

•  Product 
Assurance 

•  Management 


•Timely 

•Efficiant 

-  development 

-  modification 

•  Visible 

•  Controlled 

•  Oelact-Frea 


Integratad  Combat  Syatama 
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THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

SWTP  ITERATION  WITH  USER 
COMMUNITY 


1990 

Drafts  1,2,3 

Scoping  current  effoits,  technology  areas 

4/91 

Draft  4 

User  needs,  technology  integratioi. 

8/91 

Dran  5 

Sji  M:iric  programs;  investment  priorities 

10/91 

DraP  6 

Public  release  version  approval 
-  Funding  details  not  included 

1/92 

Contractor  and  researcher  review;  integration 
with  POM  94 

3/92 

SWTP  Public  Forum 

(3/31  -  4/2/92,  Tyson’s  Comer) 

5/92 

Baseline  Plan 

akCtwrfmktnAMS>§  aMa/n;;; 
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THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

oirrLiNE 


•  Software  Technology  Plan  (SWTP)  Overview 

•  Relation  to  SWAP 

•  Why  will  the  SWTP  make  a  difference? 

-  Driven  by  user  needs 

»  -  Focused  on  high 'leverage  strategies 

-  Integrated  across  technology  and  management 

-  Developed  by  its  responsible  implementors 

-  Focused  on  technology  transition  to  customers 

•  STARS  support  of  SWTP 

•  SWTP  participation  opportunities 
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THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

SWTP  FOCUS  ON  HIGH-LEVERAGE 
STRATEGIES 


•  Return  on  investment  (ROl)  analysis 

-  Re-engineering 

-  Reuse 

-  Process 

-  Tools 

-  Technology  transition 

•  Building  or.  strengths 

-  Oi-ganiTational  roles 

-  External  technology 


Annual  Dul) 


STARS  AND  MEGAPROGRAMMING 

PROGRAM  RESULTS  BY  SOURCE  OF 
SAVINGS 


Baselitis  Total 


Work  Avoidance 
(Reuse) 


+  Working  Smarter 
^  (  Process! 


-f  Working  Faster 
(Tools) 


1996  1998  2000  2002  2004  2006  2008 


ApM/VCJS 


STARS  AND  MEGAPROGRAMMING 

BUILDING  ON  STRENGTHS:  EXTERNAL 
TECHNOLOGY 


•  Where  possible,  get  DoD  technologiy  commercialized 

•  Or,  get  commercial  technology  DoD-ized 

-  AccommodaJng  Ada,  embedded  real-time,  high  assurance,  high 
performance  software 

•  This  makes  the  “Iron  Law  of  Software  Maintenance”  affordable 

-  “For  every  $1  you  spend  on  Software  Product  Development,  you  will 
spend  at  least  $2  on  its  maintenance” 

-  Commercialization  spreads  maintenance  costs  over  much  larger  user 
base  than  DoD 


OmC  TWJt  i 
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THE  DOD  SOFTWARE  TECHNOLOGY  PI  AN  AND  STARS 

S\\TP  INTEGRATING  STRATEGIC  THEMES 

•  Megaprogramroing 

•  High-level  re-engineering 

•  Process  support  and  fechnoiogy/management  synergy 

•  Commercial  technology  leverage 

•  Integrating  artificial  intelligence  and  software  engineering 

S  TTAJtS  i  Bmtm-rCM 
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THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

OUTLINE 


•  Software  Technology  Plan  (SWTP)  Overview 

•  Relation  to  SWAP 

•  Why  will  the  SWTP  make  a  difference? 

-  Driven  by  uset  needs 

-  Focused  on  high -leverage  strategies 

-  Integrated  across  technology  and  management 
►  -  Developed  by  its  responsible  implementors 

-  Focused  on  technology  transition  to  customers 

•  STARS  support  of  SWTP 

•  SWTP  participation  opportunities 


D»OSWrrmttfUJO/B 


THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

SWTP  TECHNOLOGY  TRANSITION 
INITIATIVES 


•  User  involvement  in  technology  development 

•  Joint  govemment/industiy/univenity  projects 

•  Process  maturity  assessments 

•  Mid-life  cost-effectiveness  reviews 

•  Stimulate  technology  advocates  and  receptors 

•  Closed-loop  IR&D  process 

•  Annual  DoD  Software  Technology  Conference 

•  Open  systems 
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THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

OUTLINE 


•  Software  Technology  Plan  (SWTP)  Overview 

•  Relation  to  SWAP 

•  Why  will  the  SWTP  make  a  diflerence? 

-  Driven  by  user  needs 

-  Focused  on  high -leverage  strategies 

-  Integrated  across  technology  and  management 

-  Developed  by  its  responsible  implementors 

-  Focused  on  technology  transition  to  customers 

•  STARS  support  of  SWTP 

•  SWT?  participation  opportunities 


OtOptTPmdlTAMSii.  i 


THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

STARS  SUPPORT  OF  SWTP 


SWTP  THEME 

STARS  SUPPORT 

•  Mcgaprogramaung 

•  SEE,  Reuse  support 

•  Commcrdal  techaoloQr  Icrcngc 

•  Primes/commerdal  counterparts 

•  CASE  vcndors/SEE  frameworks 

•  Process  npport 

•  SEE,  Process  technology 

•  Ibol  iatetntkm 

•  SEE  frameworks 

•  Metrics  and  continuous  process  improvement 

•  SEE  instrumentation 

1 

1 

•  Evahiation  projects 

090  XWTT  STAMSfU.  UdmfVQ34 

THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

STARS  TOOL  INTEGRATION  CHALLENGE 


Requirement  Engineering 
Requirements  elidation 
Protot^ing 
Domain  analysis 
Simulation  and  modeling  of 
components  and  systems 
Specification  and  reasoning 

Design  Support 
Design  elidutioa  and  process 
support 

Ar^tecturc  and  interftce 
management 
Interfoce  conformance 
Prototyping 

Assuraoec/Quality 
Tbst,  test  case  generation 
Analysis:  stadc,  semantic,  flow . 
Formal  analysis 
Inspection 

Hybrid  lest/fbrmal  analysis 
Documentation 
Searefaing,  KB  mtnirg 
Hypertext,  hypermedia 
Dragn  informadon  record 
support 
Gencratioo 


Team  Support 
Data  interchuge 
Control  flow,  access  management 
Decision  and  process  management 
Generation 
Compilers,  opdmiters 
Application  generators 
Domain  spedfic 
Muid-language  interoperability 
Component  composidon 
Life  Cyde 

Reverse  engineering 

Process  management  and  support 

Impaa  analy^ 

Reengineering 
Customiaadon,  adapudon 
Performance 

Instrumentadon  of  software/hardware 
i^ialysis 

Simuladon  of  components/systems 


Management 

Metric  dau  gathering,  perturbadon 
anal^ 

Metric  selecdon 

Metric  arulysis  and  synthesis 

VM/CM 

Thiceabiliiy 

Cost,  risk  esdmadon  and  analysis 
Tool  integradon  and  management 
Scheduling,  projecdon,  status 
Resource  allocadon  management 
Code  Management 
(specs,  code,  design,  process,  etc.) 
Syntax  analysis 

Emr  Repair 
Debugging 
Instrumentadon 

User  Interface  Design 
Menus 
Reports 
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THE  DOD  SOFTWARE  TECHNOLOGY  PLAN  AND  STARS 

PARTICIPATION  OPPORTUNITIES 

€ 

1990 

Drafts  1,2,3 

Scoping  current  efforts,  technology  areas 

4/91 

Draft  4 

User  needs,  technology  integration 

8/91 

Draft  5 

Specific  programs;  investment  priorities 

10/91 

Draft  6 

Public  release  version  approval 
-  Funding  details  not  included 

1/92 

Contractor  and  researcher  review;  integration 
with  POM  94 

3/92 

SWTP  Public  Forum 

(3/31  -  4/2/92,  Tyson’s  Comer) 

5/92 

Baseline  Plan 

79 


OfCSWT^m^STAltt/M 


STARS  ’91 

TRACK  1  PROCESS  DRIVEN 
DEVELOPMENT 


Ibesday  December  3, 1991 

2K)0-2:45  Process  Driven  Development  Vision,  Dick  Drake,  IBM 
Strategies,  and  Achievements 


2:45-3:15  Break 

3:15-4d)0  Process  Concepts 


Dr.  James  E.  King,  Boeing 


4d)(MJ0  Break 

4:30-5:15  Process  Asset  Library 

8H)0-9:30  Community  Involvement  Working 

Group:  Process  Driven  Development 


Jim  Over,  SEI 


STARS  ’91 

TRACK  1  PROCESS  DRIVEN 
DEVELOPMENT 


Wednesday  December  4, 1991 

S:30-9:15 

Experiment  in  Process  Definition 
and  Represrntation 

Carol  Klmgier,  TRW 

9:15-9-M 

Break 

9:45-10*J0 

Enaaing  the  Software  Process 

WUUam  H.  Ett,  IBM 

lO-JO-llHM 

Break 

11:00-11:45 

Process  Measurement 

Hal  Han,  TRW 

1:45-2:30 

Technology  Feedback  Session 

BUI  Hodges,  Boeing 

1 


3 


PROCESS  DRIVEN  DEVELOPMENT 

OUTLINE 


•  Background 

-  Motivation 

-  Key  terms 

•  Process  vision 

-  Assumptions 

•  STARS  strategies  and  achievements 

-  Objectives 

-  Approach 

-  Product  plan 

-  Achievements 

•  Summary 


PROCESS  DRIVEN  DEVELOPMENT 

MOTIVATION 


•  The  national  capacity  to  develop  quality  software  does  not  meet 
current  need 

•  Quality  is  a  determinant  of  cost  and  schedule 

•  Software  quality  is  determined  by: 

-  People  (skills  and  domain  knowledge),  process  and  technology 

•  Process  management  improves  the  effectiveness  of: 

-  People,  process  and  technology 

•  There  are  few  products  that  have  the  explicit  capability  to  support  a 
tailored  project-specific  software  development  process 


Why  is  software  process  imporunt?  The  national  esqaeity  to  develop  quality  software  products  in  a  reliable,  predictable 
manner,  does  not  meet  the  cutieni  need  in  the  United  Sates.  Software  produa  quality  is  a  key  deteiminant  of  both  software 
cost  and  i  wk  of  att»«tinii  to  the  quality  of  a  software  system  during  its  complete  development  cycle  will  almost 

cenaiitly  result  m  increases  m  cost  and  schedule  over  the  long  run. 

Software  quality  is  determined  by  people  (their  skills  and  their  knowledge  of  the  application  domain),  process  and  technol¬ 
ogy  used  to  produce  the  software  product.  Process  management  has  been  shown  lo  improve  the  effectiveness  of  the  people, 
process  and  techiulogy  used  to  produce  software.  However,  within  the  domain  of  software  development,  there  are  few 
products  that  have  the  explicit  capability  to  support  a  tailored,  project-specific  software  development  process.  The  STARS 
miMion  is  to  accelerate  the  availability  of  processes  and  technologies  to  suppwt  process  dnvea  dcreiopmeuL 
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PROCESS  DRIVEN  DEVELOPMENT 

WHAT  IS  SOFTWARE  PROCESS? 


Software  Process:  P  =  A^ 

•  A  set  of  Activities  performed  by 

Agents  (people  /  machines)  which  create  and  manipulate 
Artifacts  (data)  to  produce  a  system 

Software  Process  Element  —  a  component  of  a  process  ranging  from 
individual  process  steps  to  very  large  parts  of  process 

•  Examples 

-  Configuration  management  process 

-  Inspection  /  review  process 

-  Meeting  process 

fmmmt  Din» 


fini  let’s  define  e  few  key  terms  and  concqm  which  will  be  unponani  to  an  understanding  of  how  STARS  is  supponing 
the  definition  and  automation  of  software  process.  One  simple  way  to  define  software  process  is  to  look  at  it  as  a  set  of 
Activities,  performed  by  Agents  (people  or  machines),  which  create  and  manipulate  Artifacts  (data,  work  products)  to  pro¬ 
duce  a  system.  It  is  important  to  remember  Jut  process  is  always  there  whether  we  carefully  define  it  or  not  Problems 
occur  when  processes  are  poorly  defined,  misunderstood  and  inconsistenily  applied. 

Software  processes  are  made  up  of  software  process  elements.  A  process  element  is  a  component  of  a  process  ranging  iirom 
individual  process  steps  to  very  large  parts  of  a  process.  For  example  within  a  configuration  management  process  you 
might  expect  to  fmd  a  number  of  process  elements  for  oonduoing  inspections  or  reviews.  Likewise  you  would  (vobably 
find  meeting  processes  incorporated  within  a  review  processes. 
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PROCESS  DRIVEN  DEVELOPMENT 

DEFINED  PROCESS  LIFE  CYCLE 


A  defined  process  is  a  process  that  is 

•  Documented 

•  Taught 

•  Applied 

An  evolutionary  life-cycle  for 
improving  a  defined  process: 


Dmm  OmiipMai^DfiimVCS 


One  of  (he  most  important  concepts  with  respect  to  process  driven  development  is  (he  notion  of  a  denned  process.  To  qual¬ 
ify  as  a  defined  process  u  is  not  sufficient  to  have  the  process  described  in  a  noiebooic  which  can  be  found  on  the  desk  of  all 
projea  personnel  A  deOned  process  must  be  documented,  it  must  be  taught  to  the  people  expected  to  apply  it  and  it  must 
be  applied  as  documented  and  taught 

Process,  however,  is  not  a  suoc  thing.  Processes  are  consianUy  changmg  and  a  process  which  is  not  changing  is  probably 
obsolete.  Therefore,  one  must  view  process  m  teims  of  an  evolutionary  life-cycle  for  improving  a  defined  process.  A  sim¬ 
ple  way  to  think  rf  'jm  ufe  cycle  is: 

•  Defiitt  -  Establish  the  organizations  process,  adapt  it  to  ffie  specific  proiea  and  product  requirements  and  train  peo¬ 
ple  m  its  use. 

•  Use  -  Apply  the  process  as  defined 

•  Measure  -  Constantly  monitor  and  measure  the  process  as  it  is  being  peiformed 

•  Evolve  -  Continually  evolve  and  improve  (he  process  based  on  the  measurements  and  experience  gained. 

At  each  iteration  through  this  cycle  the  definition  would  be  refined. 
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Mcgaprogramming  is  an  «m«rging  paradigm  which  will  dramaDcally  change  the  way  we  produce  Sc/ftware.  A  change  of 
this  proponion  will  take  a  long  dme  to  pervade  the  industry.  A  key  element  of  this  emerging  paradigm  is  {vocess  driven 
deveiopmenL  The  following  pages  will  defuie  what  is  meaiu  by  process  driven  and  provide  some  underlying  assumptions 
about  how  It  can  be  applied. 
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PROCESS  DRIVEN  DEVELOPMENT 

PROCESS  -  DRIVEN  VISION 


•  Organizational  process  is  established  and  then  adapted  and  tailored 
to  meet  project  and  product  goals 

•  Softivare  developmer-  is  guided  by  a  defined  process 

•  Environment  and  tools  are  integrated  to  support  a  defined  process 

•  Defined  process  promotes  collaboration  and  teamwork  by  making 
activities,  roles,  and  dependencies  visible 

•  Process  management  discipline  supports  continuous  improvement  of 
the  defined  process  through  measurement  and  feedback 


Dnin 


Pro«ss  driven  devclopmeni  begins  when  an  _ uon  establishes  the  processes  necessar>'  to  suppon  their  objectives. 

These  procew*  •><*  »h»fi  •  .^jored  to  meet  dte  needs  of  the  specific  project  and  product  to  be  builu  The  software 
''  .  .Kjpment  activities  will  be  guided  by  this  defined  process  (documented,  taught  and  applied).  A  software  development 
environment  and  its  tools  would  be  established  and  integrated  based  on  the  tailored  process.  This  implies  that  you  under¬ 
stand  your  process  before  you  seiea  your  tools  to  carry  out  the  process. 

The  use  of  the  defiried  process  will  promote  collaboration  and  teamwork  by  making  activities,  roJes  (taken  on  by  agents) 
and  dependencies  visible  to  all  projea  personnel  The  discipline  associated  with  a  defined  process  will  result  in  continuous 
process  improvement  through  measurement  and  feedback  (Define,  Use,  Measure,  Evolve). 

So  in  summary,  process  driven  development  implies  that  you  have  a  defined  process  which  is  tailored  to  the  problem  and 
which  is  continually  improved  through  measuremem  and  feedback. 
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PROCESS  DRIVEN  DEVELOPMENT 

VISION  ASSUMPTIONS 


Process  creation: 


•  A  process  architectural  model  can  be  defined  that  prescribes  the 
architectural  features  of  process  components  necessary  for  their 
creation  and  use  in  process  design 


•  A  process  can  be  partitioned  into  component  parts  (elements),  that 
can  be  reassembled  into  other  eiiective,  project-specific  processes 


•  A  reliable  technique  can  be  defined  to  support  the  development  of 
project-specific  processes  from  component  parts 

Ft— Ow  Diitap— /DaaWVCI 


There  are  several  irnpoitaiu  assumptions  underiying  process  driven  developmenL  Prtxresses  will  be  developed  somewhat 
like  software  itself.  A  process  architecture  will  be  created  in  order  to  suppon  the  use  of  process  elements  in  the  construction 
of  the  process.  Process  will  be  constructed  by  assembling  existing  component  pans  to  suppon  project  and  product  specific 
requirements.  In  other  words,  the  processes  will  be  constructed  using  libiaiies  of  existing  process  elements.  Since  proc¬ 
esses  need  to  be  constructed,  tailored  and  refined,  a  ’’process  life-cycle  process”  will  be  developed  to  guide  this  process 
evolution. 
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PROCESS  DRIVEN  DEVELOPMENT 

VISION  ASSUMPTIONS  (CONT.) 


Process  automation: 


•  A  process  definition  can  be  embedded  in  and  govern  the  tailoring  of  a 
project-specific  Software  Engineering  Environment  (SEE) 

•  Process  management  within  a  SEE  will  require  specific  tooling  for 
representation,  design,  modeling,  enactment  and  measurement  of 
process 

•  Process  instrumentation  and  data  collection  can  be  automated  within 
a  SEE  by  providing  enactii.ent  services  and  data  collection  processes 


Process  driven  development  will  require  significant  automation.  The  assumptiorts  related  to  automation  include  the  nobon 
that  process  can  be  defmed  in  a  formal  enough  way  to  be  embedded  within  the  software  engineering  environment  This 
implies  that  the  process  is  central  to  the  tailoring  of  the  environment  The  resulting  environmem  will  contain  knowledge  of 
the  process  and  thereby  it  will  be  able  to  offer  many  opportunities  for  automation. 

The  management  of  large  comi^ex  software  plications  will  require  process  support  In  the  future  software  development 
environments  will  contain  support  capabilities  for  representing,  designing,  modeling,  simulating,  measuring,  enacting,  dy¬ 
namically  changing  and  evolving  software  process. 

The  key  to  process  improvement  is  measurement  and  feedback.  Software  engineering  environments  can  be  expected  to  con¬ 
tain  suppmt  for  instrumentation  and  dau  coUecdoo.  These  capabilities  will  have  a  great  potential  for  automation  in  an  envi¬ 
ronmem  which  has  an  embedded  process  definition  incorporated  within  it 
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PROCESS  DRIVEN  DEVELOPMENT 

STARS  STRATEGY  AND  ACHIEVEMENTS 


Megaprogramming— Ao  Emerging  Paradigm 

•  Process-Drivea 

•  Domain-Spedfic  Reuse-Based 

•  Teefaaoiogjr  Supponed 

•  CoUaboiadve  Development  by  Geographically 
Dispencd  Teams 


Accelerate  Megaprogramming 


0 


ptevious  pages  have  provided  context  and  definidan  to  the  Megaprogramming  notion  of  process  driven  devetopcnent 
remainder  of  this  presentation  will  concentrate  on  the  STARS  activities  in  support  of  the  STARS  mission  to  accelerate 
nnsition  to  the  process  driven  development  aspects  of  Megaprogramming. 


PROCESS  DRIVEN  DEVELOPMENT 

STARS  PROCESS  OBJECTIVES 


•  Provide  empirical  evidence  supporting  the  concept  of: 


SEE 

Process 

Support 


Improved 

Quality, 

Productivity, 

Reiiabilitv 


•  Successfully  demonstrate  the  ability  to  combine  and  adapt  software 
process  elements  to  create  project  specific  processes 

•  Successfully  demonstrate  the  benefit  of  automated  process  support 
provided  by  a  SEE 

Dew« Ti»  aifnllBhelTii 


STARS  has  an  objective  lo  demonstnue  the  value  of  process  driven  development.  This  includes  providing  evidence  sup- 
poRing  the  following  concepc 

•  If  you  Stan  with  a  good  set  of  process  concepts,  then  create  a  process  definition  to  support  the  project  and  product 
goals,  and  support  this  with  auiomaied  process  suppon  within  the  environment. 

•  Then  the  results  will  be  improved  quality,  productivity  and  reliability. 


STARS  will  demonstrate  the  ability  id  combine  and  adapt  software  process  elements  in  order  xo  create  a  project  specific 
process.  STARS  will  also  demonstrate  the  benefits  that  automation  for  the  process  within  the  SEE.  The  remaining  presenta¬ 
tions  within  this  oack  will  elaborate  on  this  concept 
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PROCESS  DRIVEN  DEVELOPMENT 

STARS  PROCESS  OBJECTIVES  (CONT.) 


•  Provide  process  and  technology  support  to  assist  software  development 
organizations  in  their  progression  up  the  SEI  Capability  Maturity 
Model  (CMM)  for  defining,  measuring,  and  evolving  the  project’s 
life  cycle  processes 


Process  Control 


Process 

Measurement 


Process 

Definition 


Process 

Discipline 


-  Provide  support  for  the  transition  to 

higher  levels  of  maturity 

-  Ensure  basic  capabilities  are  available 

to  support  Process  Driven  Development 


STARS  wi]!  provide  process  and  technology  stqtport  to  assist  software  develc^eni  organizations  in  their  progression  up 
the  SEI  Capability  Maturity  Model  (CMM).  This  includes  both  support  for  the  transition  to  process  driven  development 
such  as  concepts,  guidelines  and  techniques  as  well  as  basic  capabilities  and  tools  needed  for  process  driven  development 
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PROCESS  DRIVEN  DEVELOPMENT 

STARS  PROCESS  APPROACH 


The  STARS  approach  to  accelerating  (he  shift  to  Megaprogramming  involves  starting  with  point  solutions  and  then  evolving 
(hose  solutions  to  siqipon  software  in  the  large.  This  involves  manning  arxi  integrating  the  capabilities  within  the  software 
engineering  envitonmenL  At  the  same  time  as  the  capabilities  ate  being  matured,  STARS  will  address  cultural  issues  of 
how  to  apply  these  concepts  and  how  to  traositian  organizations  to  a  process  driven  approach.  STARS  will  focus  its  efforts 
in  three  key  areas: 

•  Process  definition  and  lepresentation 

•  Process  Asset  Library 

•  Process  enactment  and  measurement 

STARS  will  anempt  to  begin  the  instuunonalizadoo  of  the  process  driven  coiKepts  by  demonstrating  the  benefits  on  real 
DoD  projects.  The  STARS  prime  contractors  will  work  with  their  commercial  counterparts  and  the  CASE  vendor  commu¬ 
nity  to  commeraalize  the  process  support  capabilities  and  integrate  them  within  software  engineering  environments. 
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PROCESS  DRIVEN  DEVELOPME.NT 

STARS  PROCESS  PRODUCT  PLAN 


October  ’91; 

•  Prototype  process  definition  and  management  tools 

•  Experienced  tested  process  examples 

•  Evaluation  reports  and  guidelines 

October  ’92: 

•  Refinement  of  above  to  support  ’’friendly  user”  evaluation 
-  Opportunities  for  technology  transition  affiliates 

Diiia  OevMpMwfiaM/VQU 


Over  (he  last  year  STARS  process  effms  have  been  focused  on  experimenbng  with  and  evaluating  a  number  of  point  sdlu* 
tioas.  This  inctudes  prototypes  of  a  numba  of  different  process  definition  and  nunagement  tools.  STARS  in  conjunctkai 
with  the  3£1  has  gathered  bom  industry  sources  a  jiany  expeiience  tested  processes  and  has  defmcd  a  seveial  modem  proc¬ 
esses.  STARS  has  also  published  coocqns,  guidelines  and  lessons  learned  reports.  The  spedlk  items  are  described  later  in 
this  presentation  and  further  elaborated  in  other  presentations  within  this  track. 

Over  the  next  year  STARS  win  mature  these  capabilities  and  begin  integrating  them  in  software  engineering  environments. 
By  the  fourth  quaner  of  1992,  these  capabilities  will  be  applied  in  a  number  of  test  projects  (alpha  test  cases)  in  order  to 
gain  experience  to  help  iefu<e  the  capabilities.  This  may  offer  oppommities  for  interested  Tectmology  Transition  affUiaies 
to  work  closely  with  the  STARS  program. 
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PROCESS  DRIVEN  DEVELOPMENT 

STARS  PROCESS  PRODUCT  PLAN  (CONT.) 


October  ’93; 

•  Process  Asset  Library  (PAL) 

•  SEE  support  for  demonstration  projects 

-  Tools  for  definition  and  modeling 

-  Tools  to  support  process  enactment  and  measurement 

•  Guidelines  and  training  materials 

•  Establish  a  process  support  team  to  assist  demonstration  projects 

October  ’94  /  ’95: 

Refine  and  commercialize 

Kwmm  Dim  DMipMU0nMVC15 


The  STARS  demonstration  projecu  will  begin  in  October  of  1993.  At  that  time  STARS  will  have  capabilities  available  to 
support  these  projects  including  a  Process  Asset  Library  and  process  defmiuon,  modeling,  enactment  and  measurement 
tools.  Guidelines  and  training  material  will  be  available  to  support  these  capabilities.  A  process  support  team  will  be 
formed  to  provide  ongoing  sigipon  for  the  demonstration  projects. 

During  1994  and  199S,  STARS  will  work  with  the  demonstration  projects,  the  STARS  affiliates  anu  the  CASE  vendor 
community  to  enhance  and  refme  the  c^iabilities. 
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PROCESS  DRIVEN  DEVELOPMENT 

ACHIEVEMENTS 


•  Tools  and  languages  to  define  process 

-  Software  Process  Management  System  (SPMS)  prototype 
aBM/SAIC) 

-  Artifacts,  Agents  and  Activities  (AAA)  Process  Formalism 
(Boeing/Honeywell) 

-  Process  Experimentation  in  SADT,  MVP-L  and  APPL/A 
(Unisys/TRW) 


Dim 


Funher  infomuiioa  on  the  docuL'cnts,  tools  and  processes  listed  on  these  chans  can  be  found  either  through  the  STARS 
Catalog  or  through  participation  in  the  STARS  Technology  Transfer  AfiUiaies  program.  Many  of  the  capabilities  are  avail 
able  for  demonstratiotL 


PROCESS  DRIVEN  DEVELOPMENT 

ACHIEVEMENTS  (CONT.) 

•  Tools  supporting  a  defined  process 

-  Policy  representation  prototype  using  control  point  process 
enactment  mechanism  (Boeing/Honeyweil) 

-  Action  item  browser  (human  agent  interface  to  process 
enactment) 

-  Cleanroom  Engineering  Process  Assistant  (CEP A)  prototype 
(IBM/SET/UES) 

-  This  is  an  applicati  jn  of  the  Kl-Shell  product  from  UES 

-  Software  Process  Management  System  (SPMS)  prototype 
(IBM/SAIC) 

-  Interface  and  packaging  support  for  Amadeus  Measurement 
System,  available  1Q92  (Unisys/TRW) 

-  Amadeus  comes  from  the  Arcadia  project  and  UC  Irvine 

l>f«w 
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PROCESS  DRIVEN  DEVELOPMENT 

ACHIEVEMENTS  (CONT.) 


•  Processes 

-  Cleanroom  engineering  software  process  (IBM/SET) 

-  Composite  Process  Model  (Unisys/TRW) 

-  Risk-reduction  reasoning-based  development  paradigm  tailored  to 
Navy  C2  systems  (Unisys/TRW) 

-  Software-flrst  system  development  process  (IBM) 

-  SEI/STARS  joint  effort  to  acquire  experience  tested  processes 

-  Domain  analysis  process  (IBM/SAIC) 

-  Asset  certification  process  (Unisys) 

-  IEEE  P  1074  process  component  set  (SAIC) 
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PROCESS  DRIVEN  DEVELOPMENT 

ACHIEVEMENTS  (CONT.) 


•  Concepts  /  guidelines  /  lessons  learned 

-  Process  Concept*  Summary  (Unisys/Boeing/IBM/Others) 

-  Software  Process  Tools  and  Techniques  Evaluation  Report  (IBM) 

-  Process  Concepts  Scenarios  (Boeing) 

-  Process  DeHnition  Advisory  Group  (PDAG)  Workshop  Report 
(SEI) 

-  Process  Programming  Language  Experimentation  Report 
(Unisy^TRW) 

-  Process  Programming  Experiment:  Initial  Lessons  Learned 
(Unisys/TRWAJniversity  of  Maryland) 


Process  driven  dcvelo(xnem  begins  with  a  defined  process  which  has  been  tailored  to  meet  the  specific  project  and  produa 
requiFensenis.  The  process  is  performed,  monitored  and  measured.  The  feedback  is  used  to  evolve  the  process  and  refine 
the  process  definition. 
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STARS'91 


Track:  PROCESS  Sessioo:  2 
Title:  Process  Coocepts 

Itesenter.  Dr.  James  £.  King  Organizidon:  The  Boeing  Company,  Defense  &  Space  Croup 

Tbeme: 

Process-driven  Enviraunents  provide  (be  means  to  achieve  improved  quality  by  reducing  variability  in  planning,  by 
^liminaring  costly  and  error-pTOoe  sequences  of  tasks,  and  by  pnjviding  data  which  assists  in  improving  the  defined 
processes  being  used. 

Objective: 

Articulate  the  Icmg  range  concepts  and  identify  rcdiat  STARS  will  be  able  to  achieve. 

Abstract: 

What  is  a  process-driven  software  engineeting  mvironmem?  How  will  it  effea  the  way  I  work?  How  can  it  help  me 
work  better?  These  questicms  and  other  related  topics  will  be  addressed  by  examining  the  effects  on  typical  users  of 
the  environment,  the  types  of  activities  that  will  tw  affcaed.  and  the  interrelationsfaip  between  usen'  activities  that 
will  result  from  the  transitian  to  megtqxogramming.  The  coocepts  will  be  illustrated  through  scenarios  of  user 
interactioo  with  the  envisioned  process-driven  software  engineering  environment.  The  scenarios  wiU  rq^resent  user 
views  specific  to  activities  performed  by  different  users  at  various  times  in  the  life  of  a  system  development  projecL 
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PROCESS  CONCEPTS 

OUTLINE 


•  STARS  Program 

•  STARS  Process  Approach 

•  Process  Concepts 

•  Process-Driven  Development 

•  Project  Management 

•  Process  Enactment 

•  Process  Modeling  and  Design 

•  Future  Directions 

Slide  2:  Title:  Process  Coocqits 

STARS  is  focusing  its  anentioo  on  an  emerging  paradigm,  entitled  Megaprogrananing,  wfaich  is  ba«d  oo 
incoipmting: 

«  Process-driven, 

•  Domain-specific  reuse-based, 

•  Technology  supported, 

•  Collaborative  development 

tedmologies  into  software  development. 

STARS  mission  is  to  accelerate  the  shift  to  this  emerging  paradigm. 

Although  STARS  has  identified  these  four  major  thrusts,  they  are  ixx  independent.  In  fact  the  process  thrust  is 
another  instance  of  a  specific  domaiiL  Each  these  areas  which  are  presented  through  the  four  tracks  at  this 
conference  are  highly  interrelated.  The  defined  process  is  deployed  with  technology  suppon  to  provide  a  process- 
driven  Software  Engineering  Environmem  (SEE).  The  SEE  provides  network  based  collaborative  develo^ent  and 
distributed  computing  in  an  open  architecture. 

The  focus  of  this  presentation  is  to  elaborate  the  STARS  view  of  process  driven  software  development  and  how  this 
^Tnpha.<i<  leads  to  higher  levels  of  product  quality.  A  long-term  view  of  process-driven  develo{nnent  will  be 
presented.  DifTereni  views  of  this  system  u^l  be  illustrated  in  terms  of  activities  associated  with  differem  users. 
Early  point  solutions  will  be  discussed  and  the  ground-woik  laid  fer  the  STARS  process  activities. 
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PROCESS  CONCEPTS 

STARS  PROCESS  APPROACH 


Point 

Solutions 


Proc9S«  Formalisms 
•  Comparlslon  Study 
-  AAA  Process  Formalism ' 
Process  Assets 


Institutiona 
Ization 


-  Process  Asset  Library 
Proeass  Enactment 

•  ControLPoint 

•  Role-Based 
Process  Management 

•  Software  Process 


Risk  Management  Strategy  Applied 
to  Capability  Improvement  and 
integration  with  the  Software 
Engineering  Environment 


Process-Driven 
Software  Engineering 
Environment 


MgmL  System  I 

Process  Engineeriing  I 

•  Process  Modeling  / 

&  Design  Capability  / 

Process  Measurement  ^ 

•  Amadeus  Experiments 


Slide  3:  Title:  STARS  lYocess  Approach 

STARS  approach  for  developing  the  process-driven  development  capabilities  is  to  use  an  iterative  development.  lisk- 
redncti(»  iqiproach  which  begins  with  point  solutions  which  are  being  or  have  been  developed.  They  indnde  (1) 
process  formalism  comparisons  which  is  the  topic  of  a  later  session  in  this  crack,  (2)  process  formalism  definition 
which  is  used  to  specify  the  process  defimiions  used  in  the  Control  Point  Rrocess  Dei^  (3)  process  asset  coUectioo, 
the  of  the  next  session  in  this  track.  (4)  enactment  mechanisms  such  as  the  Control  Point  and  Role-Based 

solutions  which  are  being  demonstrated  at  this  coofereace  and  described  both  here  and  in  a  later  session  in  this  track, 
(5)  process  managemem  capabihties  svfaich  are  discussed  both  here  and  in  a  later  session  and  demonstrated  witii  the 
Software  Process  Mazugemem  System  (SPMS)  in  the  exhibit  area,  (b)  process  modeling  and  design  capabilities 
discussed  later  in  this  session .  and  (7)  process  metric  capability  which  is  described  in  a  later  session  in  this  trade. 
These  coocepo  and  prototypes  are  evahiaied  against  a  ri^  managemem  strategy  in  order  to  prioritize  the 
development  activities  during  each  p^iase.  Early  solutions  and  capabilities  are  integrated  as  appropriate  with  the 
develqnng  SEE  in  order  to  evaluate  further  capabilities  and  to  minimize  the  risks  in  develqnng  the  process-driven 
SEE. 
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PROCESS  CONCEPTS  j 

PROCESS  OBSERVATION  &  HYPOTHESIS 


Observation 

Having  an  agreed-upon  and  commonly  shared  software 
development  process  model  is  a  major  factor  in  an  organization's 
software  development  effectiveness  (Curtis,  Krasner,  Iscoe  ,1988). 

Hypothesis 

The  software  process  is  an  important  leverage  point  from  which 
to  address  software  product  quality  and  productivity  issues. 

The  state  of  software  engineering  practice  is  largely  ad-hoc. 

Establishing  the  use  of  defined  processes  as  standard  software 
engineering  practice  is  a  prerequisite  for  improvement. 

ftmrnirmgm* 


Slide  4:  TlUe:  Process  ObservstioD  a  Hypothesis 

As  badcgronad  for  tbe  emphasis  oo  process  driven  sofcwue  development,  there  have  been  numeioas  smdies  of 
software  projects  which  focused  on  die  effecdveness  of  an  organization  to  develqi  quality  software  prodnro  (see 
Cuitis,  Kxasw,  &  Iscoe,  198S,  Comnumicatians  of  tbe  ACTM  31  (11)  1268-87).  These  smdies  have  identified  a 
strong  conelatioo  between  the  product  quality  and  tbe  presence  of  an  agreed-upon  and  commonly  shared  software 
developmetu  process.  Recent  articles  and  conference  t^cs  have  identified  the  need  for  defined  process  to  guarantee 
repeatability,  measnrability.  and  adaptability  of  process  definitions  in  order  to  facilittte  process  improvemem. 

Some  of  the  problems  that  can  result  ftom  a  lack  of  an  explicit  process  model  are  diat  each  software  development 
projea  must  mannaDy  perform  tbe  tasks  necessary  to  pro^ice  project-specific  plans,  which  is  susceptible  to  costly, 
emr-prone  sequences  of  tasks.  In  addition,  the  plans  are  bi^y  variable  in  content  and  quality,  depending  on  the 
individnals  involved.  By  not  having  a  defined  process,  it  is  difficult  to  obtain  meaningftil  measuremen’s  of  the 
process  that  is  being  used  so  that  process  improvemem  camoi  be  obtained.  The  variability  of  processes  used  from 
projea  to  projea  means  that  any  historical  dau  gathered  is  difficult  to  conelate  and  use  to  pr^a  behavior  for 
another  project  Therefore,  a  defined  process  supports  tbe  STARS  objective  of  getting  tbe  processes  practiced  in  a 
tTnimw  that  allows  measurement  and  consequently  analysis  and  improvemem  which  promotes  improved  produa 
quality. 
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Slide  5:  Title:  Leveb  of  Abstraction 


Ctae  of  the  most  OTcmscd  words  in  recent  tedmical  discnssions  b  the  word  process.  It  has  different  m»gning  to 
different  people  It  often  takes  on  different  meaning  based  on  usage  such  as  a  process  for  an  organization 
compared  to  a  process  for  roquiroaents  traceabOitj.  In  thb  discussion,  process  b  used  to  reference  several 
different  leveb  of  abstraction.  Most  often  process  b  nsed  to  reference  the  ^ftware  Dcvdopment  Process  that  b 
used  bj  a  project  to  develop  and  evolve  the  software  product  However,  thb  ^ftware  Development  Process  b 
determined  by  compootion,  adaptation,  and  tailoring  of  process  blocks  v’bich  are  maintainoH  in  a  proems  reuse 
library.  Tbb  composition,  adaptation,  and  tailoring,  b  itself  performed  by  a  process,  the  Software  Development 

Ptocen  Process  and  instantiated,  scfaedulcd,  and  installed  by  a  Software  Pro<»  Management  Process.  Ina 
proccss-driven  development  all  of  these  leveb  are  present  Measurement  of  the  processes  in  use  suggest 
improvements  to  the  software  development  process  as  well  as  to  the  higher  level  ^ftware  Development  Process 
Process.  As  a  SEE  becomes  more  process-driven,  the  need  for  a  spedalbt  in  composing  processes  develops.  Thb 
specialist  defines  process  blocks  and  works  with  project  managers  and  software  engineers  to  adapt  the  definitions 
to  the  needs  of  the  project 
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Slide  6:  Tide:  OrgmfaatioiuJ  Intencdoa 

A  defined  process  does  not  exist  isolated  Ctom  the  iotenctions  of  tbe  development  or  siqipori  projea  and  die 
remainder  of  the  orgamzadon  and  exteatnal  stake-holders.  For  an  organizatioa  to  improve  its  ability  to  produce 
higher  quality  fsoducts,  it  is  necessary  for  the  defined  processes  to  be  adapted  and  tailored  to  other  projects  within 
the  organization.  This  process  use  wiU  provide  historical  data  which  will  rontributs  to  understanding  improvements 
in  processes  to  provide  higher  quality.  la  addition  tbe  parent  organization  provides  goals  and  constraints  relative  to 
the  business  interests  of  tbe  organization  as  well  as  resources  to  sui^iott  tbe  project. 

Many  large  development  projects  involve  numerous  subconiracts<is  that  are  often  geographically  dispersed, 
ftocesses  which  ate  designed  to  support  network-based  collaborative  develt^xneni  provide  measurement  capabilities 
and  histoiical  information  which  can  be  used  to  improve  the  processes  and  provids  lower  risk,  hi^ier  quality 
strategies  for  product  developmetu.  Often,  all  or  portiais  of  the  defined  process  are  provided  to  tbe  snbron tractors. 

Process  activities  are  often  performed  by  tools,  many  of  which  are  purchased  from  vendors.  By  establishhig  the 
interface  definiticms  for  the  product  transformations  with  the  activities  of  a  defined  process,  it  is  possible 

to  be  able  to  identify  new  or  iminoved  tooling  which  can  be  added  to  or  substituted  for  existing  capabilities. 

I 

Lastly,  by  utilizing  a  riefwied  process,  tbe  project  can  track  tbe  development  progr^  mere  accurately  and  be  able  to 
identify  risks  earlier.  This  provides  tbe  customer  with  better  undemanding  of  the  project  develupmen: 

through  accurate  management  and  engmeering  data.  A  defined  process  also  includes  a  {hocsss  for  change 
management  so  that  effects  of  proposed  changes  can  be  evaluated  accurately  and  quickly. 
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PROCESS  CONCEPTS 

SW  DEVELOPMENT  PROCESS  SCENARIO 


Consider  a  simple  software  development  and  support 
organization  which  has  received  a  requirements 
change  and  wishes  to  modify  an  existing  product  to 
conform  to  the  new  requirements. 

Develop  a  defined  process  which  specifies  the 
proceses  needed  to  coordinate  changes  to  the  desig 
the  coding,  and  testing  of  a  module  resulting  from  a 
requirement  change  request. 


A  portion  of  th«  Sixth  intomational  Software 
Proeau  WoiWng  Group  (ISPW-6)  sampla  problanv 


Slide  7;  Title:  Software  Developmeu  Process  Scenario 

In  order  to  provide  a  foens  for  disenssing  a  defined  process,  let  ns  consider  an  example  wfaidi  has  been  used  by  the 
process  community  to  examine  the  adequacy  of  a  process  fcxmalism  to  represent  some  of  the  requirements  for  a 
viable  process-driven  envircometu.  The  example  was  developed  around  several  process  issues  including: 

•  multiple  levels  of  abstraction 

•  tequeocing.  coostraints  on  sequendag,  iterative  and  concurrent  activities,  looping 

•  de^on  points 

•  feedback 

•  oeative  activities 

•  object  management,  stmemre,  attributes  and  interrelationships 
.  crgamzadonal  responsibilities 

•  (VnmnniftatOTi  r«.ehanigiT>< 

•  process  measurements 

•  human  and  tool  enactment 

•  professional  judgement  or  discretion 

•  temporal  aspects  including  versioning  and  scheduling 

•  plaimed  and  optional  sequencing  between  activities 

•  pre-  and  post-conditions  on  activities 

•  project  management  and  tracking  of  progress 
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Slide  8:  Tide:  Activity  Flow  for  Example 

The  example  sceoado  identifies  a  typical  organizadoa  mvotving  management,  software  designers  and  programmers, 
and  testers.  In  additfon  diere  is  a  requirements  change  board  and  a  co^guradon  management  activity. 
simplification,  the  activities  primatily  related  to  the  support  project  are  identified  in  this  activity  grapk 

The  support  projea  manager  is  primarily  involved  with  the  scheduling  and  assipmem  of  tasks  to  the  projea  team. 
The  manager  also  mooiton  die  develt^niem  activities.  Software  designen  are  involved  with  the  Modify  Design  and 
Review  Design  acdvides,  programmers  with  Modify  Code,  and  Test  Engineers  with  Modify  Test  Plans,  Modify  Unit 
Test  Package,  and  Test  Unh.  The  activity  boxes  aligned  vertically  can  all  be  perfonned  coocunendy  according  to 
the  example.  Some  proposed  changes  m^  not  involve  a  design  modificatian  so  that  they  could  progress  while  other 
changes  causing  design  modificadoo  are  inoorporated  in  the  design.  As  a  result  of  testing,  there  may  be  changes  that 
need  to  be  made  to  the  test  plans  that  are  independent  of  the  design  and  code.  However  the  Unit  Test  Package  must 
be  modified  based  on  the  fi^  versions  of  the  design,  code  and  test  plans.  Lasdy,  several  steps  involved  potential 
iteration  before  final  approval  is  achieved. 

Each  of  the  activities  identified  in  this  activity  graph  themselves  represent  processes  which  are  interconnected  to 
ttefine  the  projea's  process.  Each  of  the  activities  can  have  both  pre-  and  post-conditions  that  must  be  met 
before  progress  can  continue.  For  instance,  suppose  the  Support  Organization  has  decided  that  the  Modify  Code 
activity  caxmot  begin  until  notice  frexn  the  Mo^  Design  aenvipr  is  received  indicating  which  parts  of  the  software 
prodnet  are  not  affected  by  a  design  modificanoa  This  is  a  policy  that  becomes  a  pre-condition  for  starting  the 
Modify  Code  activity  and  a  post-condition  for  a  Change  Analysis  st^  within  the  Modify  Design  activity.  Other 
policies  and  ccodinons  can  imposed  based  on  the  goals  and  policies  of  both  the  Su{pon  Project  and  the  other 
stake-holders  as  indicated  earlier. 
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Slide  9:  ‘Iltk:  User  Role  i£eraicby 

Qeariy  in  a  large  software  developmenx  project,  there  ire  osmeiotu  activities  that  are  often  peifonned  by  specialists 
in  the  related  domaita  Oar  ap(ao^  in  the  STARS  view  is  to  identify  specific  user  roles  and  determine  the  products 
and  activities  with  which  dxy  interface.  These  roles  are  described  diroo^  Entity-Relatianship  models  to  more 
accorately  represent  the  role  activities.  The  roles  have  been  grooped  into  a  class  hierarchy  in  (vder  to  relate  users  to 
related  orgardzational  activities.  Depending  on  the  size  of  the  project,  one  person  may  have  several  roles  to  fill  or 
tmly  a  portioo  ot  the  rtrie  identified  in  the  hierarchy.  The  approach  to  esablishing  the  processes  and  activities  for  a 
SEE  are  centered  oo  the  roles  of  the  users  of  the  SEE.  The  Ulustratiaas  in  the  remainder  of  this  presentatian  take 
views  associated  with  tfifferent  roles. 
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Slide  10:  Title:  Process  Driven  Developmeot 

To  sanmitriro  a  process-driven  development,  ibe  process  is  defined  csing  process  examples  maintained  in  a  process 
asset  repositary  and  adt^xed  to  the  reqoiiements  at  tbe  project  and  ycdnct  This  process  drives  the  creation  of  a 
plan  and  the  scheduling  of  resontce  Qsage  consistent  with  ^  execuiiao  envirocDaenL  Tbe  instantiated  process  is  then 
installed  in  a  SEE  to  a^eve  a  process-driven  environment.  As  the  process  it  used,  measurements  are  periodically 
collected  to  assist  in  the  monitoring  of  tbe  develqxnent  progress  and  to  evaluate  tbe  effectiveness  of  tbe  process. 
Analysis  of  tbe  daa  from  process  usage  may  result  in  improved  process  definitions  wbicb  are  then  deplo^  to  be 
scheduled,  insttUed.  used,  and  monitored  for  fimber  in^iiovemeats. 

During  tbe  remainder  of  this  presentation,  various  user  roles  win  help  focus  on  portions  of  tbe  process-driven 
development  in  order  to  urtdersund  some  of  the  oonoepts  involved. 

Up  to  this  point  tbe  need  to  have  a  defined  process  for  software  develcpment  that  is  practiced  has  been  stressed. 
Marry  of  tbe  activities  of  software  development  are  performed  using  computers.  By  instantiating  the  defined  process 
activities  within  the  enviroament,  marry  rtf  tbe  tedious  tasks  such  as  monitoring  progress  can  be  automated.  The 
execution  of  tbe  plan  uirder  tbe  control  of  the  defined  process  using  tbe  automared  techniques  for  monitoring  forms 
tire  basis  for  a  process-driven  environment. 
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Slide  1 1 :  Utle:  Process  Driven  Development  (Planning} 


The  coQcqxs  of  this  process  driven  envinniment  can  be  pictorially  represented  in  more  detail  Let  us  first  look  at 
the  details  involved  in  taking  a  defined  process  model  and  developing  an  instantiated  defined  proce^  which  is 
and  as^  As  the  process  is  enacted,  process  monitoring  accumulates  information  about  the 
processes  and  products. 

This  chan  e;q>ands  pan  of  the  definidon,  scheduling,  and  process  mooitoring  acdvines.  The  activities  identified  are 
the  primary  respoosibilides  associated  widi  the  Frojea  Manager’s  role. 

The  project  manager  is  responsible  for  taking  existing  defined  process  modeb,  tailoring  and  adapting  them  to  the 
project  needs,  «»-<iahiithing  a  plan,  aUocadng  resources  to  esublish  a  schedule,  and  monitoring  the  development  for 
conformanoe  with  the  plan.  Replanning  activities  occur  when  changes  or  diflicaldes  are  encountered.  Process 
improvemeot  occurs  tlaoagfa  of  analysis  of  process  history  and  new  ideas  resulting  fiom  process  use. 
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PROCESS  MODEL-**  Defines  HOW  a  process  is  to  be  performed 

PROJECT  DATA-^-Defines  WHAT  is  manipulated  by  process. 

PROJECT  PLAN-»’lnstantiates  the  HOW  and  WHAT. 

PROJECT  RESOURCES-P-Defines  WHO  (role)  is  to  perform  a  process 
and  WHERE  a  process  is  to  be  performed. 

PROJECT  DURATIONS  AND  SCHEDULES-**Define  WHEN  parts  of  the 
process  are  performed. 

SCHEDULED  PLAN  WITH  RESOURCES-P'Combines  HOW,  WHAT,  WHO, 
WHEN,  and  WHERE. 


SCHEDULED  PLAN 

with  MONITORING  Methods 

and  ENACTMENT  mechanisms  — 


SOFTWARE  PROCESS  MANAGEMENT 
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Slide  12:  Tuk:  Software  Process  Management 

Software  process  management  can  be  simplistically  described  in  terms  of  tbe  following  concepts.  A  process  model 
in  the  most  goeral  sense  defines  how  a  process  is  to  be  performed.  It  contains  prototypical  sequences  of  tasks  that 
must  be  done  in  order  to  accomplish  desired  goals.  A  plan  is  defined  to  be  tbe  instantiated  and  elaborated 
informatian  prodnced  by  combining  process  model  and  project  specific  data.  A  process  vodel  provides  tbe 
framework  for  prodncing  plans  that  can  be  replicated  for  specific  software  developmem  projects.  It  does  noL 
however,  provide  tbe  detail  necessary  for  individnab  to  perform  specific  tasks  to  prodto  specific  products  of  a 
desired  qulity  ftv  a  q>edfic  cost  or  in  a  defined  time  frame.  Process  model  infotmatioD  must  be  combined  with 
project-specific  informatiao  to  create  a  detailed  plan  that  includes  the  cost,  schedule,  and  quality  requirements.  This 
project  specific  informatiaD  includes  dau  on  what  is  to  be  built,  who  is  available  to  perform  tbe  work,  and  where 
the  work  is  to  be  performed.  Scbednles  based  on  estimated  durations  of  tasks  and  available  resources  provide  dau  as 
to  when  tasks  may  be  started  and  completed.  Combining  the  project-specific  information  with  the  process  model 
dau  concerning  how,  provides  tbe  ba^  for  oonventitmai  projM  managemem  planning.  If  this  informatimi  is 
combined  with  antooi^ed  techniques  for  monitoring  and  supporting  some  of  the  tasks  that  individuals  trust  perform 
in  the  execution  of  the  plan,  then  it  may  fonn  the  kernel  of  a  software  process  managemem  system.  The  degree  to 
which  tbe  software  process  management  system  automatically  suppcms  and  monitars  the  ongoing  process  is,  in  p^ 
determined  by  the  process  model. 
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Slide  13:  Title:  Software  Process  Management  System  (SPMS) 

As  an  example  of  an  early  STARS  point  solutkn  consider  the  Software  Process  Management  System  developed  as  a 
STARS  Breaktfaroagb  Initiative  and  adopted  as  part  of  the  IBM  STARS  strategy  for  incaporatioa  within  (hr  STARS 
process  sohitioos. 

•  Focuses  on  the  activities  associated  with  Slide  11. 

•  Gwered  in  more  detail  in  Sesskxi  "Software  nocess  Management* 

•  Illustrated  by  the  SPMS  Demonstrstian  in  dte  exhibit  ludL 
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PROCESS  DRIVEN  DEVELOPMENT 

(Enactment) 


Important  Roles 

•  Software  Engineer 

•  Programmer 

Software  Dcrelopment  Process  in  USE  •  Testing  User 

•  System  Engineer 
•Coniignration  Mami^  ^ent 

•  SEE  AdministTator 


Slide  14:  Title:  Process  Drirvcn  Devdopment  (Enactment) 

Now  let's  focus  on  the  programmers,  software  engineers  and  other  users  of  a  process  driven  development  that  arc 
directly  related  to  the  enactment  of  the  defined  proccsSi  The  enactment  concepts  of  this  process  driven  environment 
can  be  pictorially  represented  in  more  detaO.  Tliis  chart  rspands  the  enactment  monitoring  activities.  It  focascs 
primarily  on  the  activities  associated  with  the  cn^cers  and  developers  of  the  project  products. 

As  examples  of  STARS  point  soiadons,  two  di/Tcrent  strategics  have  been  examined  for  process  cnactmenL  The  first 
of  these  involves  attaching  actions  to  the  pre-  and  post-operations  of  activities  to  notify  and  control  the  behavior  of  the 
SEE.  The  second  involves  monitoring  activities  in  the  cevironment  and  presenting  to  nser  the  appropriate 
current  view  of  the  development  so  that  the  user  may  sdect  the  next  activity  from  choices  which  are  appropriate  to  the 
user's  role. 
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S'ide  15:  Title:  Cootrol  Poim  Process  Emctmem 

Tbe  first  type  of  enactnent  involves  some  fandamesial  mteracdoa  witb  the  environment  fianework.  Various 
fanctions  are  a>'ailable  for  invocadoo  in  order  to  perform  tbe  activities  related  to  the  process.  Tbese  include  editors, 
compilers,  browsers,  and  function  evaluators.  An  undotying  assumptioa  about  ibis  ^pe  of  enactment  is  that  every 
(^xratiOD  is  perfcxmed  utilizing  a  function  model  which  has  an  entry  event  and  an  exit  event  associated  with  tbe  body 
of  tbe  funcaoa  A  history  of  the  events  is  tnamtairwri  and  tbe  events  can  trigger  acnons  which  are  called  control 
points.  Further  informatian  regarding  control  points  is  provided  in  the  short  extract  fiom  tbe  Process  Operadon 
Concqits  Document  endded  ftocess  Concepts  Scenarios,  available  in  the  lituratnre  for  this  rack 

Associated  with  a  cootrol  point  is  an  enable/disable  parameter  which  can  be  dynamically  set  during  execudoa  A 
mvtirinn  based  OD  ptocess  and  product  state  variables  which  are  maintainrd  in  a  persist  store  is  also  associated 
widi  the  control  poitu.  If  the  control  point  is  enabled  and  tbe  coodidoo  is  true  tfam  tbe  body  of  the  control  point  is 
CoDtTOl  points  aTC  tbenuelves  funcdois  so  that  they  have  the  events  and  body  to  express  the  desired 

behavior. 

Another  factor  that  affects  enactment  is  related  to  policies  that  are  enforced  reladve  to  the  specific  behavior  desired. 
For  in<taTtr>,  an  Ada  design  process  may  have  a  policy  such  as  'only  individnals  witb  5  ye^  of  Ada  coding 
experience  are  allowed  to  pcrfcmm  this  acdvity’.  To  determine  the  truth  of  this  policy,  it  is  necessary  to  detenniae 
who  is  the  acdvity,  what  are  the  quallficadais  of  tbe  user  and  whether  or  not  the  user's  qualificadons  meet 

tbe  requirements  of  the  policy. 


Once  tbe  policies  are  to  be  satisfied,  the  enactment  of  the  activity  can  occur.  In  this  view,  both  humans 

and  tools  can  be  the  martmmt  agents  for  the  activity.  Tool  invocation  occun  through  the  normal  scheduler  in  tbe 
enviionmem.  If  a  human  is  the  agent,  tbe  person  must  be  notified  about  wfaai  is  expected  to  be  done  and  why.  This 
is  »rrnmpTi«;hi»H  thiough  an  Acdonltcm.  The  Acdonitem  message  is  sent  to  the  user  with  appropriate  instructions  for 
accomplishing  the  activity. 
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Slide  16:  Title:  Ptx»ess  User  Nodficatiop 

Assumixig  1  series  of  Actkniltems  bive  resulted  front  development  activities,  how  would  the  user  interface  appear? 
To  facilitate  navigating  through  the  Acttanltem  messages,  an  Actiooltem  Browser  has  been  developed  which  forms 
the  primary  user  interface.  When  a  user  logs  into  the  system,  the  user  may  select  the  Actiooltem  Brosvser  to  inspect 
activities  that  have  been  assigned  to  the  user.  Thus  the  user's  view  of  the  system  is  often  through  the  Actiooltem 
Browser. 

Retnming  to  the  example  described  in  Slides  7  and  8,  that  a  request  to  change  a  requirement  has  just  been 

processed  by  the  Chaii^  Board  and  the  Change  Approved  actioo  has  been  selected.  As  part  of  the  completico  of  this 
action,  an  Actiooltem  is  created  for  the  Software  Manager  to  respood  to  the  change  request  As  a  result  the  action 
item  illustrated  is  sent  to  the  manager.  The  Actiooltem  Browser  allows  infonnation  related  to  the  Actiooltem  to  be 
identified  and  collected  so  tiuu  the  manager  can  review  any  infannation  before  a  dedsion  about  tire 

Actitreltem.  Fcr  tins  Ulustratiao,  tire  software  matuger  may  view  the  originating  change  request  the  requirement 
involved  in  the  change  or  tire  tiAfa  involved  processing  the  change.  At  any  tinto  the  manage  may  obtain 
sensitive  help,  review  opticres  defined  for  tire  manager's  task  or  commit  the  chosen  action. 

This  actiem  item  has  identified  two  actitns  that  can  be  taken  by  tire  manager.  The  managw  may  accep*  the  change 
request  and  trigger  the  activities  necessary  to  inylement  the  change  or  can  reject  the  change  which  will  cause  a  post¬ 
condition  to  ask  for  an  explanation. 

This  enactmem  mechanism  has  been  developed  izuo  a  STARS  point  solntiao  and  is  being  denxnstrated  at  this 
conference  by  the  Boeing/Hoireywell  STARS  team. 
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An  objact'tMssd  approach  Is  usad  to  record  and  enact  a  METHOD  which  Is: 

•  a  model  or  description  of  RCIES, 

•  ACTMDES  that  consthihe  the  work>flow  process  that  must  t>e  completed  by  each  role, 

•  APPUCATiONS  that  must  be  Invoked  within  the  activities,  and 

•  DATA  that  must  he  manipulated. 
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Slide  17:  Title:  Role-Based  Process  Enactment 


The  second  mechanism  of  process  enactment  is  based  on  gnidance  provided  in  a  role-sensitive  context  Many 
methodologies  associated  with  software  development  identify  the  activities  associated  with  different  user  toIm 
associated  with  the  methodology.  These  defined  activities  can  be  incorporated  into  a  process  definition  which 
supports  the  methodology  and  can  be  organized  around  the  associated  roles.  In  leims  of  Role-Based  Process 
Enactment  the  role  specific  subprocess  is  called  a  method.  The  method  describes  the  activities,  applicatitms,  and 
dau  that  are  associate  with  the  role.  The  method  is  then  instantiated  in  the  environmem  along  with  process 
monitoiing  capabilities  to  enable  user  process  guidance.  When  a  user  logs  into  the  system,  the  user  is  assigned  to  a 
role.  The  user  may  change  roles  if  he  has  proper  anthority.  The  steps  in  the  enactment  of  the  isocess  are  selected  by 
the  user  nntil  the  task  is  completed. 

This  nvirhiinicin  15  being  demonstrated  by  the  STARS  IBM  team  as  the  Qeanroom  Engineenng  Process  Assistant 
(CEPA).  It  is  discussed  in  more  detail  in  the  Software  Process  Management  presentation  later  in  this  track. 
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Slide  IS:  Title:  Softwsre  Eogmeoing  Manaser  RnAomunt  View 


Briefly,  the  available  activities  that  can  be  peifmced  by  the  user  are  presented  throogb  a  gnqibical  interface.  The 
nser  sdects  an  activity  which  resnlts  in  eiths  a  snbproc^  activity  of  selecting  from  speciflc  s%  bactiviiies  or  results 
in  direct  invocatioo  ^  applications,  tailored  to  the  specific  of  the  user  »n<t  current  stats*  ot  the  project 
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r*  Project  Manager 
:  •  Repository  Specialist 


'n 
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Sli<le  19:  Title:  Process  Driven  Development  (Process  Engineering) 


So  far  we  bave  focused  on  project  managers  and  die  programmen,  software  engineers  and  otber  users  of  a  process 
diivea  devdopmeru.  An  impoitaiu  part  of  a  process-driven  environment  is  the  creadon  and  modiftcadon  of  process 
defimtions  and  models.  STARS  has  idendfied  this  as  the  process  engineering  role.  The  process  eogineeiing  concepts 
of  the  environment  can  be  pictorially  represented  in  more  derail,  TI^  chart  e:q>ands  the  definjpfm  activity  and 
focoses  primarily  on  the  acdvides  assocUted  with  the  process  engineers  who  create  and  adapt  process  assets,  process 
models  and  tailor  the  process  mcxlels  for  use  by  a  project. 

The  development  of  process  assets  is  the  focus  of  the  ftocess  Asset  Libraiy  presentadoo  in  this  track.  The 
devdopmeru  of  proc^  models  has  been  invesdgtted  using  two  different  approaches.  The  IBM/SAIC  SPMS 
protot^  previously  discussed  in  slide  13  and  pan  of  the  Software  Process  Managonent  preseruadon  incorporates 
conposidoo  of  process  models  from  process  assets.  A  second  approach  involves  devdqping  a  behavior  model  of  the 
processes  using  approaches  to  system  engmeering  coocept  devdopmeni  or  software  gngwvwTng  G\S£ 


PROCESS  CONCEPTS 

PROCESS  MODELING  & 
DESIGN  CAPABILITY 


Slide  20:  Tide:  Process  Compodtiop 

The  deoils  sssocisted  with  this  qjproach  axe  docmncBted  is  a  shot  extract  from  the  draft  Process  Operatioaal 
CoQcqpts  Document  enrttlfid.  ftoc^  Concepts  Scenarios  available  in  the  limnnoe  for  this  ndc. 
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Slide  21:  Title:  Process  EnginBering  Activity  loiegratioQ 

Process  engineering  activities  tie  iaterreleted  with  many  other  sctivines  in  the  SEE.  As  an  inegiation  point  for  the 
activities  of  all  the  STARS  participants,  process  engineering  tries  to  compose  a  process  which  is  used,  measured 
and  evolved  so  that  hi^ier  quality  produra  can  be  predictably  developed.  STARS  is  developing  three  instances  of  SEEs. 
Each  of  these  SEEs  must  be  able  to  enact  die  defin^  pocesses  seltctri  by  the  projea  for  developmeiu  of  a  software 
systemu  Individnally,  each  envirooinent  performs  smnlar  activities.  Corporately,  ^  envirooments  utilize  assets  and 
contribute  process  assets  to  a  common  Process  Asset  Library.  The  intent  is  to  develop  process  support  capabilities  that 
can  be  mstandated  on  each  of  the  imtanms  of  the  SEE.  This  provides  coordinatioo  beroeen  each  of  the  programs  and  a 
combined  value-added  caruzibution  which  esceeds  each  participana  individnal  contribution. 
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PROCESS  CONCEPTS 


PROCESS  DRIVEN  DEVELOPMENT 


S]i'>^22  Title;  Process  Drivea  Devclquem 

Tying  a!!  of  the  pens  together,  the  hi^.  level  pictorial  view  of  e  ptocess-drivea  environment  is  obtained. 

What  win  STARS  accomplish? 

•  Eaily  Poim  Sohztioos 

•  Ride  reduction  activities  R’mdemmdcomidexity 

•  Planned  t»oductevotution  and  inooipotatioo  into  the  SEE 

•  TaloiaUe  piocess  asseu 

•  CoDcepu  tested  on  demonstration  ptojea  and  refined 


STARS ’91 

Process  Asset  Library 


JtaamW.Onr 

*ii<>inn  rnfiimrim  tiMriiiiU 
03  Dcntar  1991 
(413)288-7Q4 
jwti^m  I  um  wh 


Abstract 

Based  on  the  results  of  Software  Engineering  Institute  (SEI) 
assessments,  the  state  of  software  engineering  practice  is  immature. 

As  a  consequence,  software  cost  and  schedule  are  largely  unpredictable 
and  quality  is  lacking.  The  software  process  provides  an  important 
leverage  point  from  sriiieh  to  address  software  productivity  and  quality. 
To  mature  and  improve  the  software  process  will  require  Ae  use  of 
defined  processes  as  standard  software  engineering  practice. 

One  way  to  leverage  this  capability  (defined  processes)  into 
widespread  practice  is  to  make  tailorable,  adaptable  examples  of 
experience-tested  software  processes  readily  available.  In 
collaboration  with  the  STA^  prime  contractors,  the  SEI  is  leading  a 
joint  efibrt  to  develop  a  library  of  reusable  software  engineering 
processes.  Together,  the  SEI  and  STABS  prime  contractors  will 
demonstrate  the  benefits  of  reusable  process  assets  within  the  STARS 
process<entered  environments. 

This  presentation  provides  an  overview  of  the  effort  to  develop  the  asset 
library,  and  initial  results  of  a  recent  STARS/SEI  workshop  on  process 
asset  library  concepts. 
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Pro«M«  AMt  Libfwy 

Outline 


Motivation,  Olyectives,  and  Approaeii 


Initial  Baaolta 


Fotw*  Directioa 
Oppoitnaity  to  Partieipato 
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ProcAM  AM«t  Library 

Motivation  for  Process  Improvement 


Softwar*  product  quality  is  datsmiaad  by 
tba  quality  of  tha  peopla,  procasaa>  T  asd 
taclmology  mvohrad  in  its  productioa. 


pnocess 


Tha  stata  of  aoftwara  sniinasrinf  practiea  is  largaly  ad>hoe. 


Tha  software  proeaas  is  an  important  lavaraca  point  from  which 
to  addraas  aoftwara  product  quality  and  prodnetiTity  issnas. 


Proeasaas  ara  improaad  throng  foenaad 
aaolntionary  eyelaa. 


Dagna 

EvaJuata^^  Usa 
Maasura 


anfinaarinf  praMtioa  is  a  praraquiaita  for  improaamant. 


Many  software  organizations  are  facing  the  critical  challenge  of 
developing  quality  software  in  a  reliable  and  predictable  manner. 
People,  technology,  and  process  are  the  three  leverage  points  that 
organizations  have  to  meet  this  critical  challenge. 

People  are  currently  our  most  important  resource.  Personnel/team 
capability  is  the  most  significant  cost  driver  in  software  development . 
But  even  the  best  people  require  the  infirastructore  provided  a 
disciplined  process  in  order  to  do  their  work. 

Technology  has,  and  will  continue  to  enable,  the  development  of  better 
qualify  software  products.  But  the  effective  use  of  tedinology  requires 
that  technology  Iw  woven  into  the  falvic  of  the  software  process. 

Based  on  the  results  of  SEI  assessments,  the  state  of  the  practice  is 
largely  ad-hoc  There  is  little  process  disdpline,  and  low  process  Sdelify 
(adherence  to  defined  processX 

Process  has  been  proven  to  be  a  very  effective  qualify  leverage  point  in 
other  inductries,  and  early  result  from  software  process  improvement 
efforts  have  demonstrated  comparable  benefits.  Product  drfects  are 
halved  or  better,  return  on  investment  is  on  the  order  of  7  to  L 

Because  many  organizations  have  the  most  trouble  defining  and 
executing  the  steps  that  transform  user  needs  into  a  software  product 
(Le.  the  software  process),  focusing  on  installing  a  defined  process  can 
provide  substantial  benefit  while  maximizing  the  effectiveness  of 
existing  technology  and  people. 

To  improve,  an  organization  must  get  defined  processes  into  practice, 
then  begin  the  measurement  and  evaluation  cycle  that  leads  to 
continuous  process  improvement 
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ProoeM  AaMt  Library 

Motivation  for  Process  Asset  library 


Th«  trwuitioa  firoin  ad-hoe  pracdoM  to  procAM-driTen 
dooelopmaat  ia  ehaUencmf. 

AetivitiM  inelado: 

•  idaatifyixic  and  evaloatiiic  praetioaa 

•  dafiaias  docamantinf  a  aoftwara  pro  c  aw 

•  iaidal  pilotm(/tastins  of  tha  aoftwara  prooasa 

•  tailoxins^adaptiac  a  aoftwara  proeaaa 

•  eraatins  *  proeaaa-oriantad  oiyanizatioxwl  enltiira 

Makiat  taOorabla,  adaptable  azamplae  of  aoftwara  proeaaaaa 
readily  available  will  faeilitata  the  traaaitioa  to  proeaaa  driven 
davalopBiant 

Damonatratiac  baaafita  of  prooaaa-drivaa  davalopmant  will 
aeealarata  adopdoa 


Establishing  tha  use  of  defined  process  as  a  standard  software 
engineering  practice  is  difBeult  and  expensive.  There  are  many 
challenging  activities,  including; 

*  identifying  and  evaluating  practices 

•  defining  and  documenting  an  effective  software  process  including  a 
process  firamework,  process  models,  standards,  templates,  guidebooks 
and  training 

•  piloting  or  testing  the  process  to  ensure  usability  and  applicability 

•  creating  an  organizationa]  culture  that  is  based  on  a  disciplined 
approach 

One  strategy  that  reduces  the  risk  of  meeting  this  organizationa] 
challenge  is  to: 

*  undertake  at  the  national  level  a  nsk  reducing  exercise  that  will  make 
available  experience-tested  models  and  examples  of  software  process,  and 
supporting  materials  that  facilitate  transitioo 

*  and  demonstrate,  throu^  application,  the  benefits  of  this  approach  to 
convince  others  to  take  the  risk 

By  establishing  and  applying  a  library  of  reusable  process  assets,  this 
joint  STARS/SEI  effort  can  accelerate  the  adoption  of  defined  processes 
as  a  standard  software  engineering  practice,  ami  thereby  meet  its 
mission  objectives  with  respect  to  process-driven  development 
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Proeeaa  Aaaat  Library 

Joint  SEI/STASS  Process 
_ Asset  Library  Objectives _ 

D«T«lop  a  library  of  raoaabU,  tailorabbk,  adaptabla, 
azparianoo-toatad,  ar'ftwara  aBcincarinc  proeoasas 

•  to  apply  and  aTaloata  tba  proooas  aaaet  library  eoncapi 

•  to  aarra  aa  a  atartuic  point  for  fnrtbar  alaboration 

Daaalop  mathoda  and  eritaria  for  oompoainc  projactapaeifie 
prooaaaaa  firom  eomponanta 

Oamonatrata  tba  in  aariooa  eontaxta 

•  aariaty  of  OoD  toftwara 

•  Binltipla  taebnolocy  baaaa 

•  difXarant  oryanixatioEai  aattinfa 

Tranaitioa  into  aridaapraad  naa 


To  moat  this  naad,  tha  SEI  and  STARS  have  ondertaken  this  joint 
activity  to  develop  a  prototype  of  a  Process  Asset  Labraiy  to  apply 
and  evaluate  this  "accelerate  by  example"  transitian  strategy. 

The  work  wiB  serve  as  a  stalling  point  for  farther  elaboration  and 
refinement,  goided  by  the  evaluation  of  this  initial  application. 

This  effort  will  include  the  oolleetion,  cataloguing,  analysis, 
psrtitioaing,  distillation,  and  synthesis  of  software  processes 
lobmitted  industry,  government,  and  academic  organizations. 

Other  processes,  methods,  and  criteria  will  be  developed  to  scipport 
the  composition,  tailoring,  adaptation,  installation,  and  evolution  of 
the  libraiy's  process  assets. 

The  SEI  and  STABS  will  partiripate  in  the  use  of  the  PAL  on  STARS 
demonstration  projects  in  order  to  demonstrate  the  benefits  of  this 
approach. 

As  the  library  and  methods  mature,  an  effort  to  transition  this 
approadi  into  widespread  use  will  be  undertaken. 
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To  be  successful,  an  effort  of  this  type  requires  broad  participation. 
Many  varied  capabilities  must  be  assembled  and  applied  to  the 
task.  STARS  and  SEI  working  together  have  the  combined 
organizational  characteristics  required. 


The  SETs  mission,  and  on-going  work  in  the  process  area, 
including  process  capability  maturity  modeli^,  process 
assessment  and  evaluation,  and  process  definition,  metrics  and 
improvement  work  play  an  important  role  in  this  task.  The  SEI  is 
therefore  weU-position^  to  serve  as  a  focal  point  for  the 
coordination,  development,  support,  and  transition  activities 

The  STARS  mission  in  the  shill  to  megaprogramming,  especially 
its  focus  on  process  and  supporting  tedinology  provide  a  capability 
for  maturing  the  required  tedirology  base  and  providing  access  to 
pilot  projects  for  testing. 

The  SEI  and  industry  will  coQaborate  to  make  available  the 
experience-testec*  processes  that  will  be  used  as  source  material  for 
the  library 

The  Process  Definition  Advisory  Group  will  provide  the  broad 
community  participation  that  will  be  necessary  to  evaluate  and 
transition  the  library,  in  order  to  achieve  success. 


Proo>—  Awt  JJbraty 

Process  Definition  Advisory  Gronp 


PorpoM  of  tho  Proc— ■  Dofi&ition  Advisory  Group  (PDA  G) 

•  ensure  broed  perticipstion 

•  provide  e  formn  to  end  debate  issues 

•  refine  objeetivea  and  evolve  requirements 

•  review  products 


Purtieipants  include  leading  professionals  from  industry, 
govenunent,  and  academia 


Level  of  involvement 

•  forty  to  fifty  partieipants 

•  two  meetingi  per  year 


Initial  meeting 

•  PDAG  Worimboj^  October  1-S,  1991;  Pittsburgh,  PA 

•  topics  of  discussion  inclwdet  naage  scenarios,  process 
architecture,  and  process  asset  types  and  instanres 

•  summary  report  available  by  January,  1992 


The  Process  Definition  Advisory  Grottp  (PJAG)  was  convened  to 
ensure  broad  participation  in  the  Prtx^s  Asset  Library  (PAL)  effort, 
and  to  provide  a  forum  for  defining  and  debating  issues  related  to 
the  task. 

The  PDAG  also  participates  in  the  refinement  and  evolution  of 
objectives  and  requirements  for  the  PAL,  and  in  preduet  review 

Over  fiffy  people  were  invited  to  the  the  first  meeting,  forty 
attended.  Response  to  the  first  meeting  justifies  the  er^tion  of  a 
PDAG  correspondents  mailing  list.  Ihese  members  wQl  receive 
copies  of  the  PDAG  meeting  summaiy  reports,  and  are  invited  to 
provide  feedback. 

The  initial  meeting  was  held  on  October  1  to  3,  at  the  Holiday  Inn, 
Pittsburj^  PA. 

This  meeting  was  conducted  as  a  workshop,  to  define  issues, 
objectives,  and  requirements  in  three  areas: 

•  PAL  usage  scenarios 

•  Process/PAL  architectural  concepts 

•  Process  asset  types  and  instances 
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Proe«M  Aaaet  Library 

Process  Definition  Advisory  Group 
_ Participants _ 

Participants  list  from  October  1*3, 1991  FDAG  Workshop 


Dr.  JtM  W.  AndtM  GTt  • 
Mr.  Paul  C.  Ara0ia;IBMPSD  • 


Dr.  Bafftr  Bala;  laatfumaiiU  ' 

Dr.  WUSam  Curtia;  SaSwwt  Ea>ioaatiaf 
Ma.  Batty  Diiiail;  Saftwa  CsgiMaria^ 
Mr.  Jarry  T.  Dalajwt  Ueim  tW«a 
Mr.ftcMX  Ormkt:  fflMFSD 


MrJaaaiE.K^  Baa^Dafasat  A  9pacaG«u«p 
Ma.  fiarbaru  C.  SaObMut;  IBM  Car^acuoac 

Mr.U«bKfMMr,  9AJC  _ 

Ma.  An  B.  Mamar>5e&ra^ 

Mr.  gaa>«*a*>>  K  Mmsc  TaB«  bastt 
Dr.WanmMwMtr  Taa 


Xnaath  T.  Nmk  ATST  • 

Mr.  Tlmthy  G.  OMae;  Saftwara  Eaftoaeriar  iaatitata 


Mr.WiCiaaaBti:  ffiMPS) 

Or.PattrPate'.  SaftvaiaEinaaartetlvSMa 
Mr.  Mb  ParuMB;  Saftwu  CatlaaarBia  I&aStaia 
Ma  Juba  L  Cak;  SaSuai'i  Kaoaaanaf 
Ma  IMa  P.  Cataa:  SaSnw  f  tin  nr  iff  iBaStata  * 
Mr.BalBait;  TBW 

Dr.  Daaau  BabaMcBar:  CatarM^  af  CalaraSa 
Dr.  Ma  R.  Maha  Jr.;  SaOrura  rntinainnt  liaHWiia 
Mark D.  taiarBc;  Baainf  Aarupaai  and  glactiuuirt  * 
Dr.  Man  L  Salbair.  SaAvaiu  Ea^Baanaf  ttiaiiau  * 
MsEabaft  BackiyvaQ 


riT  I  aa  T  riiiaraait:  Utbuamty  af  Cahtaraa.  Irriaa 
Mr.  Jaaaa  W.  Oaar  Saftma  Tngmmnrif  !aaiitaa  * 
Mr.  Rabat  Parte  Saftvvu  EsfiaMriBc  laattaa 
MaMaraH.ruwirin  TRW 
Mr.  Rkhaid  W.  PMUte  IBM  CoryaratiaB 
Dr.  Jary  R.  Purm;  uaaru  OMna  9y«aaa  * 

Dr.  H.  Diaur  Baahadi;  Prnfiaa 
Mr.  pBBaid  Sava;  Mb^  Softwmru  Pngifiaaint  Piatita 
Mr.  laBald  B  WQ&a;  Hoabaa  Aircnft  Caaapaay 
Mr.  Jaaaaa  V.  TTnhaj:  Sad— iu  Bapaaaiaf  tantaia 


•Mf  bardCtMajoiatSnOTABSPrBflwA— tUbmyteBk 
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ProBw  A— »t  Librmry 


Process  Asset  library  Task  Plan 


>  Produa 

Predua 

PmdLia 

Tms 

(MMdee 

OMign 

The  PAL  task  is  one  of  seven  elements  of  the  STARS  Process  effort 
planned  throng  October  rf  1995.  These  elements  are: 

•  Coordiution  and  planning 

•  Process  definition  technologjr 

•  Process  asset  libraiy 

•  Process  enactment  technology 

•  Integratioo  and  test 

•  DemonstratioD  project  support 

•  Technology  traunfion 

STARS  technology  is  being  evolved  by  experimenting  with  point 
solutiotu,  then  integrating  and  maturing  these  through  early  use 
and  applicatiai.  An  iterative  development  model  supports  this 
evolution 

The  PAL  effort  will  also  be  done  iteratively,  producing  several 
iterations  or  increments.  Eadi  increment  will  consist  of  four 
product  engineering  activities: 

•  Pr^uct  de^tion 

•  Product  design 

•  Product  development 

•  Test  and  integration 

PDAG  meetings  at  regular  intervals  wiQ  provide  guidance  to  the 
development  effort,  and  review  of  the  woik  products. 

Though  depicted  here  as  four  equal-length  phases  of  six  months 
each,  later  increments  may  be  longer  resulting  in  fewer 
increments. 
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Proeeii  A— t  Library 

Summary  of  October  1*3 
PDAG  Workshop  results 

Fociw 

•  loBg'tena  and  abortitann  naaga  aeanarioa 

•  prooaaa  and  PAL  aTchitaetural  eoncapta 

•  aaaat  i.ypaa  and  inataneaa 

Baanlta 

•  100a  paga  aammaiy  report 

•  a  rariaty  of  oaaga  aeanarioa 

•  azamplaa  of  arehitaetnral  eoncapta 

•  a  *mind*map"  of  proeaaa  aaaat  library  eoncapta 


The  PDAG  workshop  of  October  1-3  prodiiced  a  large  quantity  of 
information  that  will  contribute  to  the  development  of  the  PAL. 

The  workshop  focused  on  PAL  long-term  and  short-term  usage 
scenarios,  ar^tectural  concepts,  and  components  or  asset  types  and 
their  instances 

Results  were  impressive  and  are  beyond  the  scope  of  this 
presentatian,  but  hi^hlisd>ts  include: 

•  1004-  page  summary  report  covering  outyut  from  each  of 
sis  discussion  groups 

•  a  variety  of  usage  scenarios  for  various  roles  and  functions 

•  examples  of  architectural  concepts  frinn  other  disciplines 
and  the  application  of  these  concepts  to  PAL  or  process 
architecture 

•  a  ’’mind-map"  containing  properties,  fimctions,  and 
asset  types  for  a  process  asset  library 

The  summary  report  will  contain  all  of  the  workshop  products.  To 
provide  some  insist  into  the  contents,  this  section  of  the 
presentation  will  feature  summaries  and  examples  of  the  work 
products  of  the  PDAG  discussion  groups . 
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.Prnn—i  A— fct  Libimiy 


Process  Asset  Library  Properties 


D«riv«d  firom  experMnoe-tMtAd  procMa  model*  to  rednc* 
•doptioa  rick 

Sopport*  the  oompositioB  of sSestlZfi  projoet-cpocifie  proee— ■ 
fir««  eomponent* 

Hu  wcll-definod  proeu*  amhltoctiire  and  finuuwork  that  fnida 
asut  eiaatioa  and  oompoaxtioa 

laeladM  procau  aalaetioa,  tailoriaf;  and  adaptation  gnsdaliiM* 
and  preeamu 

Enoonraga*  proeaw  fidelity  and  fanproremant  againat  quality 
objactiTu 

FaeilhatM  maasaramant,  aaalnation,  and  arolntion  of  ita 
oontanta 


The  foUowing  represent  properties  of  the  PAL  derived  firom  the 
workshop  discussion  which  were  captured  on  video  tape. 

The  woikshop  participants  agreed  that  the  PAL  should  contain 
examples  of  ezperienoe>tested  process  in  order  to  reduce  adoption 
risk. 

Also,  the  PAL  needs  to  support  the  eompositioa  of  effective  processes 
form  its  component  parts.  In  other  wor^  it  should  make  it  easier 
to  produce  a  usable,  appUeable  process  that  promotes  product 
qu^ty  otgectives. 

This  property  is  facilitated  by  the  process  architecture  and 
framework  such  that  these  guide  the  compositior.  process  to  yidd 
effective  processes  and  effective  assets. 

The  PAL  needs  to  include  its  own  processes  for  the  selection, 
tailoring,  and  adaptation  of  assets.  OuideliDes  or  criteria  that  drive 
these  processes  should  also  be  included. 

The  PAL  most  support  the  achievement  of  the  key  motivators  such 
as  process  fidelity  and  process  improvement 

Finally,  the  PAL  should  facilitate  the  measurement,  evaluation,  and 
evolution  or  improvement  of  the  assets  it  contains. 
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Proc— A— t  LibraiT 

Process  Asset  Library  Concepts 


PAL 

PAL 

CaxM 

-  -^.11 

Prinury  users: 

•  process  ea^ineers 

•  project  menegers 

•  softmre  engineers  and 
other  process  psrticipsnts 

PAL  context 

•  national,  organixationa],  and  project 

•  library  support  mechanisms 

•  PALe  inchidea  scope  mechanism, 
support,  gnidanoe,  contents 

PAL  assets  include: 

•  process  activities,  aitilaets,  agents, 
lolea 

•  relationships  between  components 

•  metrics  and  measnrement  processes 

•  historical  data 


Several  interestiiig  concepts  emerged  from  the  PDAG  workshop. 

Some  provided  confirmation  of  existing  PAL  concepts,  others  provide 
fresh  insight  into  the  near  and  longterm  possibilities. 

A  commonly  shared  view  among  most  participants  was  the  primaiy 
osers  or  roles  that  need  to  be  supported.  These  include  personnel 
from  an  orgaxiizations  Software  Engineering  Process  Grrap,  referred 
to  as  process  engineera.  Project  managers  will  also  make  use  of  a 
PAL  as  their  role  expands  to  include  process  management 
responsibilitiea.  And  it  was  felt  that  other  uaers  sudx  as  software 
engineers  and  other  participants  might  need  to  have  access  to  the 
PAL 

Several  contexts  were  discussed.  The  notion  of  the  PAL  as  a 
national,  organizational,  and  project  library  of  assets  was  explored. 
The  underlying  technology  su^  as  Ubraxy  mechanisms  also  received 
some  attention.  Finally  to  help  distinguish  some  of  these  dimensions 
as  weQ  as  others,  the  term  PAL^  has  been  coined  as  an  overarching 
term.  Dimensions  inside  PAL^  include  scope,  mechanisms,  support 
tools,  gvddanoe  and  training,  and  the  contents  of  a  library. 

Examples  of  assets  to  be  found  in  the  library  include  activities, 
artifacts,  agents,  roles,  relationships  between  components,  metric 
and  measurement  processes,  and  historical  data. 
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ProoeM  Aaaat  Library 

Future  Direction 


Next  Step* 

•  refine  conceptual  view  of  PAL 

•  deeign  ’bnild^to*  teapUtee  for  component* 

•  constmet  component* 

•  intograt*  and  te«t  acaia*t  «>**£•  aoonario* 

•  hold  broad  reriew  (FDAG  ^  ^92) 


Near'term  recoH* 

•  FDAG  Workshop  Snnunary  Boport  Jannary  *92 

•  Proce**  Asset  library  prototype  April  *92 


il* 


Near*tenn  future  direction  includes  the  analj^s  of  the  October 
PDAG  workshop  to  establish  additional  requirements,  ^nthesixe 
usage  scenarios  and  arehitectural  concepts  to  refine  the  conceptual 
and  structural  models  of  the  PAL. 

Subsequently,  "build'to*  templates  for  component  types  will  be 
doklgned,  and  then  populated  with  instances  of  process  from  the 
evolving  archive  of  experience-tested  processes. 

The  components  will  be  integrated  and  tested  against  the  usage 
scenarios  and  presented  for  review  at  the  next  PDAG  workshop 
tentatively  plaimed  for  April  '92. 

Near-term  results  include: 

•  PDAG  Summary  Report  from  the  October  PDAG  Workshop 

•  Process  Asset  Library  prototype  for  the  April  '92  PDAG 
Workshop 
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rrooM  A«Mt  Libruy 

Opportunity  for  Participation 


5gli!T  ia  conjoactioa  with  STARS  is  providing  additional 
opportonitiaa  for  participation  for  your  organization 

Prooaaa  Definition  Adviaory  Gronp  participant 

•  attend  PDAG  woiUbojpe 

•  partieipata  in  FDAG  eomapondenoe  gronp 

•  I  e<  eire  ?DAG  workahop  anzaaaaxy  reporta 

Prooaaa  Aaaet  Librafy  eontribator 

•  provide  exemplary  proeeea 

•  partieipata  in  davelopmaat  aa  STARS  or  SEI  affiliate 

•  rapport  development  aa  alpha/beta  near 


To  further  encourage  broad  participation  in  this  activity,  the  SEI  in 
conjunction  with  STARS  is  providing  additional  opportunities  for 
partieipation  for  your  organization  as: 

•  Process  Definition  Advisory  Group  participant 

•  Process  Asset  Ubraiy  contributor 

plaasa  complete  the  following  form,  indicating  your  desired 
partieipation  and  mail  or  FAX  to: 

Jim  Over 

Software  Enginaering  Institute 
Camegje  Mellon  University 
Pittsburgh.  PA  152134890 
FAX  (412)  2684758 


or  send  e-mail  to:  jwo9saLemn.edo 


□  PDflS  participant  □  PBL  contributor 


STARS  '91 
EXPERIMENT  IN 

PROCESS  DEFINITION  AND  REPRESENTATION 


Carol  Diane  Kliogler 
TRW 

4  December  1991 

f703)-«76-8S73 

klingler^rwacs.fp4rw.com 


This  presenuiion  will  explain  ihe  reasons  for  defining  a  process  and  show  some  examples  of  a  few  of  the  many 
different  notations  that  can  be  used  for  representing  this  process  dcrmiiion. 
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EXPERIMENT  IN  PROCESS  DEFINITION 

OUTLINE 


•  Introduction  to  process  definition  and  representation 

•  Process  definition  achievements 

•  Experiment  in  process  definition  and  representation 

•  Process  definition  experiment  goals 

•  Four  candidate  representations  of  "Analyze  Asset"  process 

•  Results  of  the  experiment 

-  Experiment  comparison  of  process  notations 

•  Experiment  lessons  learned  about  process  definition 

•  Experiment  conclusions 


Arana  DtrmuimiKlij<tU>iVC2 


In  this  presentation,  we  Hrst  introduce  the  topic  of  process  definition  and  tepitsentation.  We  then  mention  the  process 
dcTinition  achievements  that  have  involved  the  STARS  project  The  remainder  of  the  briefing  examines  one  particular 
process  experiment  carried  out  by  TRW  for  STARS.  The  goals  of  the  experiment  are  shown  and  the  example  process 
that  was  examined  is  outlined.  A  small  portion  of  the  process  definition  is  shown  in  four  different  candidate  notations. 
At  the  end  of  the  prcscnuiiion,  we  present  a  comparison  of  the  candidate  notations,  the  lessons  learned  in  the  experiment 
about  process  definition,  and  the  conclusions  that  wc  made  from  the  experiment 
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EXPERIMENT  IN  PROCESS  DEFINITION 

INTRODUCTION: 

PROCESS  DRIVEN  DEVELOPMENT 


Adapitd  from  Softwart  Productiviry  Ccnsortum  work. 


To  create  quality  software,  wc  need  to  improve  our  software  development  process.  Before  a  process  can  be  improved,  it 
must  first  be  studied  To  study  a  process,  it  must  first  be  defined.  This  figure  shows  where  process  definition  fits  into 
the  process  driven  development  lifecycle.  When  a  project  begins,  the  project's  software  development  process  is  defined, 
within  the  scope  of  the  p^icular  project  or  product  The  process  definition  may  include  process  assets  .''ound  in  a 
Process  Asset  Library  (PAL),  tailored  to  meet  the  project  needs.  As  process  definitions  arc  developed,  they  may  also  be 
placed  in  the  PAL  for  use  by  future  projects.  When  the  process  definition  is  complete,  the  process  is  scheduled  and 
installed.  The  process  is  then  used  (enacted)  to  execute  the  project  As  project  execution  continues,  the  process  is 
monitored  and  measured,  and  this  data  is  fed  back  to  the  process  evolution  task  in  which  the  process  definition  is 
improved  and  refined. 
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EXPERIMENT  IN  PROCESS  DEHMUON 

INTRODUCTION: 

REASONS  FOR  DEFINING  A  PROCESS 


•  Assurance  of  product  quality 

•  Team  coordination  and  communication 

•  Process  environments  with  integrated  tools 

•  Control  and  monitoring  of  process 

•  Understanding  and  insight  into  pi  ocess 

These  different  reasons  for  defining  a  process  give  rise  to  different  types  of 
process  representation  languages. 


-  t 


A  process  must  Tirst  be  defined  in  order  to  be  studied  and  improved.  This  slide  shows  some  of  the  reasons  for  defining  a 
process.  The  main  reason  for  defining  a  process  is  to  study  and  improve  the  process  to  ensure  the  quality  of  the  product 
that  is  created  by  the  process.  Another  goal  is  to  fiKilitate  coordination  and  communication  between  team  members 
carrying  out  the  process,  such  as  managers,  software  engineers,  quality  assurance,  configuration  managers,  testers,  etc. 
Another  reason  to  define  a  pnxess  is  to  develop  a  mxhine-enactable  process  definition,  which  can  be  used  to  create  a 
process  environment  with  integrated  tools  to  support  the  software  engineers.  A  goal  at  the  opposite  extreme  of  the 
spectrum  is  the  goal  of  controlling  and  monitoring  the  process  to  "lay  down  the  rules"  for  how  the  process  is  carried 
out  by  the  software  engineers.  The  integrated  support  environment  and  control  goals  are  two  extremes  that  must  be 
carefully  balanced  to  allow  software  engineers  the  freedom  to  be  creative  while  still  allowing  project  management  to 
control  the  over^l  process.  Another  reason  for  defining  a  process  is  to  provide  understanding  and  insight  into  the 
process,  for  the  research  aim  of  studying  the  process  itself.  These  different  reasons  for  defining  a  process  give  rise  to 
many  different  notations  that  arc  us^  to  represent  a  process  definition.  The  different  notations  are  not  mutually 
exclusive.  A  combination  of  noutions  may  be  used,  tailored  to  fit  the  project  goals. 
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EXPERIMENT  IN  PROCESS  DEFINITION 

INTRODUCTION:  REFERENCE  MODEL  FOR 
PROCESS  REPRESENTATION 


L;iycr 

S  vnta.\ 

Semantics 

E.xampic 

Notation.s 

U.scr 

OrgDiii/ntionnl 

Inrurmal 

Informal 

English 

Software 
Engineers 
and  Project 
Manager 

Arcliitccturai 

Scmi-l‘'ormal 

In  formal 

Data  Flow 
Diagram 

Project 

Manager 

Design 

Formal 

Formal  - 
Operational 

MVP-L 

Process 

Engineers 

Program 

Formal 

Ftinnal  - 
Operational 

APl’L/A 

Prticess 

Engineers 

Enactment 

Formal 

Formal 

Macliine 

Code 

Macliine 
_ 1 

A  process  is  defined  by  represen'ing  it  in  one  or  more  noiaiions.  Tbcrc  is  no  one  correct  notation  to  use.  Different 
notations  may  be  used,  at  different  levels  of  abstraction,  depending  on  the  reasons  the  process  is  being  defined  and  the 
level  of  deuil  needed.  This  chart  shows  a  reference  model  for  process  representation  developed  by  STARS.  This 
reference  model  serves  as  a  means  for  talking  about  processes  at  various  levels  of  detail,  and  as  a  focal  point  for 
discussing  representations  which  arc  more  appropriate  for  specific  levels.  For  example,  at  the  organizational  layer,  a 
process's  requirements  may  be  spccifieo  in  ^glish,  with  informal  syntax  and  semantics.  Once  analyzed,  these 
requirements  may  be  translated  into  an  architecture  in  a  graphical  or  hybrid  graphical/tcxuial  notation,  such  as  Data 
Flow  Diagrams.  At  the  architectural  layer,  notations  have  a  semi-formal  defined  syntax,  which  can  be  lailoicd  to  the 
needs  of  the  particular  process  definition  activity.  Below  the  architectural  layer,  at  the  design  layer,  a  textual 
representation  language  is  used,  such  as  MVP-L.  This  is  the  layer  in  which  process  engineers  formally  define  the 
process  m  a  notation  with  a  formal  syntax  and  formal  semantics.  Notations  at  this  layer  may  be  translated  from  the 
notation(s)  used  at  the  architectural  layer.  Below  the  design  layer,  at  the  program  layer,  the  process  is  coded  in  a 
notation  at  a  level  of  detail  sufficient  for  enactment  on  a  machine.  Again  the  notation  may  be  partially  or  fully 
translated  from  the  notation(s)  at  the  layers  above.  The  lowest  layer  is  the  enactment  layer,  in  which  the  process  code 
is  run  on  the  machine.  These  process  representation  layers  do  not  portray  concrete,  absolute  boundaries  for  process 
definition  activities.  A  specific  process  notation  may  be  appropriate  at  more  than  one  layer.  Process  representations  in 
any  layer  may  be  enacted  by  humans.  Lee  Ostcrvcil.  in  a  paper  entitled  "Software  Processes  arc  Software  Too", 
suggests  that  the  development  of  process  represenutions  should  follow  a  pa.mdigm  similar  to  development  of  a 
conventional  sofrv.are  product,  and  will  include  activities  such  as  requirements  analysis,  high-l?\cl  design,  low-level 
;n,  and  coding.  These  activities  correspond  to  the  organizational,  arcuiieciural.  design  and  program  layers  cf  ihc 
rc'cicnce  model.  Ostcrwcil  continues  his  analogy  by  suggesting  that  the  aciiviiy  of  building  explicit,  formal  softw  are 
I  .acess  rcprcscp'aiions  be  referred  to  as  process  programming,  and  that  the  resulting  represenuuions  by  called  process 
programs.  This  is  the  reason  why  many  notations  suiuible  for  use  at  the  program  layer  arc  referred  to  as  proccs.s 
programming  languages.  Proccs.s  rcprc.scntauons  in  any  layer  arc  usually  definuJ  by  process  engineers.  Or.cc  defined, 
process  rcprcscniations  in  the  archncciual  layc  may  be  used  by  project  managers  lo  gam  an  undcrsu'nding  of  ihc 
overall  procc,ss  archiicciurc.  Proccs.s  reprcicntaiions  in  the  organizational  layer,  .and  possibly  the  arcliiiccujr.il  layer,  arc 
usually  used  by  the  individuals  carrying  out  the  process  to  guide  them  in  their  tasks.  In  the  design  and  program  layers, 
the  process  representations  arc  used  pnmari'y  by  'he  process  engineers  who  have  developed  them.  In  the  cnacLmcni 
layer,  the  process  is  rep' 'seated  by  machine  code,  which  is  used  by  the  machine  to  enact  the  process. 
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EXPERIMENT  IN  PROCESS  DEFINITION 

PROCESS  DEFINITION  ACHIEVEMENTS 


-  Composite  Process  Model 

-  Risk-Reduction  Reasoning-Based  Development  Paradigm  Tailored  to  C  ^ 

Systems 

-  Software-First  System  Development  Process 

-  Domain  Analysis  Process 

-  Certification  of  Reusable  Assets  Process 


Prom  Otf\mitB¥KU^ttnVC6 
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STARS  has  been  involved  in  many  process  detinition  activities.  We  have  participated  in  efforts  involving  the  use  of  a 
number  of  notations  used  to  define  processes,  for  example  the  box  struaine  notation,  used  in  the  Ocanroom 
Engineering  Software  Process;  Extended  ETVX,  used  in  tfic  Software  Process  Management  System  (SPMS);  and  the 
Artifacts,  Agents,  and  Activities  (AAA)  Process  Formalism,  used  in  the  Policy  Representation  using  Conuol  Point 
Process  Enactment  Mechanism.  Prototype  demonstrations  of  these  three  sj’stems  can  be  seen  at  STARS  '91,  and  fact 
sheets  and  oLher  documentation  is  also  available.  STARS  has  also  been  involved  in  defining  many  processes,  including 
the  processes  listed  at  the  boaom  of  this  chart.  The  remainder  of  this  presentation  discusses  a  STARS  experiment, 
performed  at  TRW  under  subcontract  to  UNISYS,  in  which  a  Certification  of  Reusable  Assets  process  definition  is 
represented  in  a  number  of  different  notations. 


EXPERIMENT  IN  PROCESS  DEFINITION 

PROCESS  DEFINITION  EXPERIMENT  GOALS 


•  Leam  about  process  definition 
-  Determine  potential  benefits  of  process  definition 


-  Determine  costs  of  process  definition 

-  Inv  igate  suitability  of  existing  languages 

-  Recommend  an  approach  to  process  definition 

•  Evaluate  the  MVP-L  and  APPL/A  process  notations 


Example  process:  Certification  of  Reusable  Assets  Process 

•  Evaluate  whether  an  asset  is  suitable  for  library  inclusion 
-  Prepare  asset  for  inclusion  into  library 

•  Load  asset  into  library 


Our  expcrimcnf  involved  a  case  study  in  process  definition  and  representation,  by  a  small  team  of  individuals.  We 
wished  to  leam  about  the  benefits  and  costs  of  defining  a  process.  We  also  wished  to  investigate  the  suitability  of 
some  existing  notations  for  use  by  process  engineers  without  prior  familiarity  with  the  notations.  This  is  an  important 
aim  because  much  of  the  work  on  the  use  of  process  notations  is  being  performed  by  the  same  organizations  that 
created  the  notations.  We  wanted  to  present  an  unbiased  opinion  on  the  appropriate  uses  of  some  noutions  currently 
available.  We  also  planned  to  write  down  our  lessons  learned  and  recommend  an  approach  to  be  used  by  other 
organizations  to  define  processes.  We  examined  18  notations  used  to  represent  a  software  change  process,  in  an  exercise 
at  the  6th  International  Software  Process  Worieshop  (ISPW).  After  careful  considerations,  the  notations  were  narrowed 
down  to  two.  MVP-L  and  APPL/A.  These  notations  were  used,  along  with  English  descriptions.  Data  Flow  Diagrams, 
and  Hierarchy  Chans,  to  represent  our  process  definition.  The  Certification  of  Reusable  /.ssets  process  defined  in  the 
experiment  consists  of  evaluating  whether  an  asset  is  suitable  for  inclusion  in  a  reuse  library,  using  domain  analyses 
and  other  evaluations,  preparing  accepted  assets  for  inclusion  in  the  library,  and  loading  them  into  the  library.  The 
entire  process  is  too  large  to  examine  in  this  presentation  and  is  highlight^  in  our  "Process  Programming  Languages 
Experimentation  Report".  We  have  also  produced  a  paper  on  our  use  of  the  MVP-L  process  representation  language. 
Both  of  those  reports  arc  available  to  anyone  interested.  In  the  remainder  of  the  presentation  we  focus  on  one  process 
element  in  the  Certification  of  Reusable  Assets  process,  namely  the  process  of  analyzing  an  asset  to  produce  the 
evaluations  used  to  determine  if  the  asset  is  suitable  for  inclusion  in  the  particular  reuse  library.  We  show  the 
representation  of  this  process  clement  definition  in  four  different  candidate  notations,  English,  Data  Flow  Diagram, 

.M  VP-L  code,  and  APPL/A  code.  We  also  discuss  the  advantages  and  disadvantages  of  each  of  these  notations,  as 
determined  from  our  experimenL  These  examples  will  illustrate  a  few  of  the  many  varied  methods  in  which  a  process 
may  be  defined. 
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EXPERIMENT  IN  PROCESS  DEFINITION 

CANDIDATE  1:  ENGLISH  DESCRIPTION  OF 
"ANALYZE  ASSET"  PROCESS 


Data  is  collected  on  a  submitted  asset  to  determine  if  it  is  suitable  for 
inclusion  in  the  reuse  library.  The  data  is  summarized  in  the  asset 
evaluation  forms,  which  are  placed  in  the  asset  reuse  folder.  This  data 
may  include  ratings;  size,  complexity,  and  other  metrics;  deficiency, 
performance,  and  trust  test  results;  formal  mathematical  analyses;  and 
domain  analyses.  The  data  is  collected  by  a  Reuse  Engineer,  using  the 
asset  identification  form  and  the  submitted  asset,  and  reviewed  by  a 
Senior  Engineer. 


This  slide  coni'»ins  an  English  dcscripiion  of  the  'Analyze  Asset'  process.  Anyone  involved  in  software  development 
has  seen  English  descriptions  of  elemenu  of  the  software  development  process,  for  example,  programming  standards, 
test  procedure',  and  conrtguration  management  manuals.  This  description  shows  that  the  'Analyze  Assa'  process 
consists  of  a  Reuse  Engineer  collecting  data  on  an  asset,  using  the  asset  itself  and  an  identincaiion  form,  and  placing 
this  data  in  the  evaluation  forms.  These  forms  are  then  reviewed  by  a  Senior  Engineer. 


EXPERIMENT  IN  PROCESS  DEHNITION 

ADVANTAGES  AND  DISADVANTAGES  OF 
ENGLISH  DESCRIPTION 


Advantages: 

•  Very  high  flexibility 

•  Very  high  completeness 

•  High  understandability 

Disadvantages: 

•  Lack  of  conciseness 

•  No  machine  analyzabiiity 

•  No  machine  executabilitv 


Frota$  0€fyiitt^KUft^^VC9  I 

This  chart  shows  the  advantages  and  disadvantages  of  using  English  descriptions  to  represent  a  process  dcrmiiion,  as 
determined  from  our  experiment.  English  descriptions  of  processes  are  very  flexible;  a  process  can  be  described  in  many 
different  ways  in  English,  depending  on  the  process  definition  activity’s  goals.  The  process  can  be  completely  described 
in  English,  due  to  the  wealth  of  words  available.  English  words  are  also  very  easy  for  humans  to  understand,  since  no 
special  knowledge  is  needed  If  a  lot  of  detail  is  not  required,  a  process  can  be  easily  described  in  a  small  amount  of 
space  in  an  English  description. 

However,  the  English  description  lacks  conciseness.  The  ambiguity  of  English  and  the  lack  of  formal  syntax  and 
semantics  leads  to  a  process  definition  that  can  be  interpreted  differently  by  different  people.  Also  the  process  definition 
cannot  be  analyrxd  and  executed  on  a  machine,  due  to  the  lack  of  formal  syntax  and  semantics.  The  lack  of 
analyzabiiity  makes  it  difficult  to  determine  whether  an  important  ponicn  of  the  process  is  left  out  of  the  English 
description. 
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EXPERIMENT  IN  PROCESS  DEHNITION 

CANDIDATE  2:  DATA  FLOW  DIAGRAM 
FOR  ’’ANALYZE  ASSET”  PROCESS 


Submitted 

Asset 


tOtf, 


The  Flow  Diagram  in  this  chan  shows  one  possible  graphical  representation  of  the  "Analyze  Asset"  process.  This 
diagram  illustrates  that  the  submiued  asset  and  idemincation  form  are  input  to  the  "Analyze  Asset"  process  and  the 
evaluation  forms  are  produced. 


EXPERIMENT  IN  PROCESS  DEnNITION 

ADVANTAGES  AND  DISADVANTAGES  OF 
DATA  FLOW  DIAGRAM 


Advantages: 


•  Very  high  understandability 

•  High  conciseness 


Disadvantages: 

•  Low  completeness 

•  Low  flexibility 

•  Low  machine  analyzability 

•  No  machine  executability 


This  chan  shows  ihe  advcniages  and  disadvanuges  of  using  Data  Flow  Diagrams  to  represent  a  process  dermiiion,  as 
determined  from  our  eaperiment  The  Data  Flow  Diagram  is  very  simple  and  easy  to  understand,  and  consequently  a 
good  notation  to  cse  to  communicate  a  process  dermition  to  project  managers  and  panicipants.  It  is  a  concise  notation; 
the  entire  "Analyze  Asset '  process  can  represented  in  one  small  diagram.  However,  there  arc  important  a.spccts  of 
the  process  that  arc  missing;  for  example  the  criteria  used  to  determine  when  the  process  may  start  and  stop  and  the 
names  of  the  participant'  in  the  process.  There  is  litde  flexibility  in  this  notation.  The  notation  allows  some  machine 
analysis  and  no  machine  txecution  of  the  process.  Some  of  the  mote  advanced  graphical  notations  that  are  used  to 
define  processes  have  so'ne  of  the  characteristics  that  are  missing  from  Data  Flow  Diagrams  but  we  have  not  yet 
examined  these  graphicai  notations.  We  will  be  examining  the  SADT  graphical  notation  in  a  follow-on  experiment. 
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EXPERIMENT  IN  PROCESS  DEFINmON 

CANDIDATE  3:  THE  MVP-L  PROCESS 
REPRESENTATION  LANGUAGE 


•  Developed  at  University  of  Maryland 

•  Believe  larger  payoffs  from  high-level  process  guidance  rather  than 

automating  parts  of  the  process 

•  Process  modeling  in-the-large 

-  Describe  interactions 

•  Facilitate  communication  and  coordination 

•  Language  design  goals 

•  Build  descriptive  models  of  processes,  products,  attributes,  &  resources 

-  Instantiate  process  models  for  specific  project  plans 

-  Provide  libraries  of  reusable  models 

1 


The  Multi-View  Process  Modeling  Project  (MVP),  at  the  University  of  Maryland,  developed  a  rule-based  language 
called  MVP-L.  This  language  is  one  of  a  number  of  textual  process  representation  languages  that  can  be  used  to 
represent  a  process  at  the  design  laya  of  representation.  The  MVP  project  believes  that  larger  payoffs  can  be  gained 
from  high-level  process  guidance  rather  than  by  automating  small  process  elements  on  a  computer.  Thcieforc,  MVP-L 
was  designed  for  modeling  the  entire  process  *in-ihc-largc'.  The  Iwguagc  concentrates  on  describing  the  interactions 
between  process  activities  to  fasiliutc  communication  and  coordination  between  the  team  members  who  carry  out  the 
process.  MVP-L  allows  rennement  and  abstraction  of  processes,  so  that  the  entire  process  can  be  described  at  the 
highest  level  and  then  broKcn  down  into  its  components.  The  language  contains  process  models  which  describe 
activities  carried  out;  product  models  which  describe  the  artifacts  used  and  created;  attribute  models  which  contain 
attributes  of  processes  and  products,  for  example,  process  status;  and  human  and  tool  resources,  which  are  the  agents 
that  carry  out  the  process.  Project  plans  assemble  process  models  and  instantiate  them,  adding  project-specific 
information;  for  example,  the  total  amount  of  time  allocated  to  the  effort.  Each  MVP-L  process,  product,  attribute  and 
resource  model  is  a  separate  units  to  facilitate  the  creation  of  a  library  of  reusable  models,  which  can  then  be  tailored  for 
a  specific  project.  Formal  syntactic  and  semantic  definitions  of  the  language  have  been  developed.  At  the  present  time, 
the  language  does  not  include  tools  for  graphical  viewing,  analysis,  or  nuchine  execution  of  MVP-L  code,  but  these  arc 
important  parts  of  the  research  effort  that  will  be  addressed  more  fully  in  the  future. 
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EXPERIMENT  IN  PROCESS  DEHNITION 

MVP-L  CODE  FOR 
^ANALYZE  ASSET” PROCESS 

EXPORTS  effort :  Process_Effort_Model  :=  0; 

CONSUME_PRODUCE 

submitted_asset :  CONSUME  Submitted_Asset_ModeI; 
identification_form  :  CONSUME  Identification_Form_Model; 
evaluation  forms  :  PRODUCE  Evaluation_Forms_IVIodel; 

LOCAL  ENTRY  CRITERIA 
submitted_asset^tatus  =  'submitted*  AND 

identification_form.status  =  'complete*; _ 

LOCAL  EXIT  CRITERIA 

evaluation_forms3tatus  =  'complete*  OR  submitted  asset^tatus  =  'rejected'; 

PERSONNEL_ASSIGNMENT 
Reuse_Engiiieer :  Reuse_Engineer_Resource; 

Senior_Engineer  :  Senior_Engineer_Resource; 

This  slide  presents  a  portion  of  the  code  thai  is  needed  to  represem  \he "  Analyae  Assti"  Pnxess  in  MVP-L.  The 
'EXPORTS*  section  contains  the  ’efTon*.  which  is  an  attribute  describing  the  amount  of  time  spent  so  far  in  the 
"Analyre  Asset*  process.  The  *CONSUhffi_PRODUCE*  section  describes  the  products  (documents  or  other  artifacts) 
used  by  the  process,  in  this  case  the  *submitted_asset"  and  the  "identiCc3tion_form",  and  the  products  created  by  the 
process,  in  this  case  the  *eva!uaiion_forms.*  The  'LOCAL.ENTRY.QflTERlA'  describe  the  condinons  ne'ressary  for 
the  process  to  start  execution.  When  these  conditions  become  true,  a  human  decides  when  the  process  actua'ly  begins. 
In  this  case,  there  must  be  an  asset  that  was  submiued  and  a  completed  idendneation  form  in  o^er  for  the  Vmalyze 
Asset"  process  to  be  ready  for  execution.  The  ’LOCAL_EXrT_^]TERIA"  describe  when  the  process  terr.iinatcs.  In 
the  "Arlalyze  Asset'  process,  the  process  ends  when  the  evaluation  forms  have  been  completed  or  the  subn  iued  asset  is 
rejected.  The  submiued  asset  may  be  rejected  at  any  time  by  the  ■Scnior_Engineer'  if  it  is  felt  that  the  effort  required  to 
evaluate  the  asset  is  not  worth  the  lime  that  would  be  spent  The  "PERSONNEL_ASSIGNMENT'  'iciion  indicates 
that  *Analyze  Asset"  is  carried  out  by  a  ■Reuse_Engineer'  and  a  "Senior_Engineer'. 
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EXPERIMENT  IN  PROCESS  DEFINITION 

ADVANTAGES  AND  DISADVANTAGES  OF 

MVP-L  CODE 


This  chart  shows  the  advantages  and  disadvantages  of  using  MVP-L  code  to  represent  a  process  definition,  as  determined 
from  our  experiment.  MVP-L  code  is  a  very  concise  noution  for  describing  in  a  modular  manner  the  parts  of  a  process, 
the  products  used  and  created,  and  the  interactions  between  processes.  These  modules  can  be  easily  uilotcd  and  reused 
on  different  projects.  We  did  not  find  the  language  to  be  wordy,  or  contain  unnecessary  features.  The  language  contains 
all  of  the  features  needed  to  specify  processes  at  the  dcsip  layer,  although  in  a  very  few  instances  we  thought  of 
alternate  structures  that  may  have  been  helpful  The  University  of  Maryland  is  evaluating  our  recommendations  and 
making  any  necessary  changing  to  the  MVP-L  language.  In  our  opinion,  for  a  textual  language,  MVP-L  is  easy  to 
understand.  The  language  uses  natural  English  words  that  make  the  models  easy  to  read.  It  contains  some  flexibility, 
especially  in  the  methods  provided  for  describing  how  cicibutes  change  values.  However,  there  is  no  static  or  dynamic 
machine  analysis  or  machine  execution  currently  supponed  by  the  language. 
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EXPERIMENT  IN  PROCESS  DEFINITION 

CANDIDATE  4:  THE  APPL/A 
PROCESS  PROGRAMMING  LANGUAGE 


Developed  by  University  of  Colorado  as  part  of  the  DARPA  Arcadia 
program 

Flexible,  machine-executable  support  for  the  object  management  needs 
of  process  programming 
Superset  of  Ada 
Language  design  goals 

-  Integrated  support  for  persistent  data 

•  Data  abstraction 

-  Representation  of  the  relationships  among  objects 

•  Automation  of  object-management  processes 

•  Flexible  model  of  consistency  and  transactions 


^foctss 


APPL/A,  ihc  Ada  Process  Programming  Language  based  on  Aspen,  is  a  language  useful  for  process  rcprcscntaiions  at 
the  program  or  coding  layer  of  abstraction  It  was  developed  by  the  University  of  Colorado  as  pan  of  the  DARPA 
Arcadia  project  to  provide  flexible,  machine-executable  suppon  for  managing  the  products  cteai^  and  used  by  piocesscs. 
The  language  contains  the  large  variety  of  constructs  needed  to  represent  a  process  at  the  high  level  of  detail  necessary 
to  allow  the  enactment  of  the  process  on  a  machine.  APPU'A  is  a  superset  of  Ada,  which  contains  all  of  the  Ada 
constructs  plus  new  constructs  for  product  management.  It  provides  integrated  suppon  for  the  storage  and  retrieval  of 
persistent  ^ta.  Persistent  data  is  data  that  needs  to  be  retained  in  storage  over  tong  periods  of  lime,  even  when  the 
process  has  finished  executing.  Data  abstraction  is  provided  through  Ada  constructs.  The  products  and  relationship: 
among  products  can  be  stored  as  data,  through  the  use  of  a  construct  ctJlcd  a  "rcbiion”.  An  example  of  a  relationship 
that  could  be  stored  using  a  ’relation"  is  the  compilation  relationship  which  creates  object  code  from  source  code. 

There  are  also  constructs  available  to  run  automated  processes  automatically;  for  example,  when  source  code  is  stored, 
the  code  could  be  automatically  compiled  to  create  and  store  the  object  code.  Other  features  ensure  consist£.icy  and 
allow  specialized  transactions.  Continuing  our  previous  example,  the  consistency  feature  could  be  used  to  ensure  that 
there  is  object  code  in  the  data  store  for  each  instance  of  source  code.  An  example  of  the  specialized  transactions  is  the 
"atomic"  statement,  which  allows  a  process  to  exclude  other  processes  from  accessing  the  data  store  when  the  process 
will  be  changing  the  data. 
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EXPERIMENT  IN  PROCESS  DEFINITION 

APPL/A  CODE  FOR 
"ANALYZE  ASSET”  PROCESS 

TYPE  Analysis_Type  IS  TUPLE 

asset_ID  :  Asset_ID_Type; 

asset”version  :  Asset~Vefsion_Type; 

evaluation  forms  :  Eval  Forms  Type; 

END  TLTLE;" 

ENTRY  INSERT  ( 

asseMD  :  Asset_ID_Type; 

asset_version  :  AsseCVersion_Type; 

evaluation_fonms :  EvalJForms_Type); 

TRIGGER  BODY  get_metncs  BEGIN  LOOP  SELECT 

UPON  asset_analysis.insert  ( 

asset_ID  :  Asset_ID_Type; 

asset_version  :  Asset_Version_Type; 

evaluation  forms  :  Eval  Torms  Type) 

ACCEPTANCE  DO 

run  metrics  collection  (asset  ID,  asset  version,  evaluation  forms); 

OR  TERMINATEfEND  SELECT;  END  LOOP;  END  get_metrics; 

This  example  shows  a  small  portion  of  the  APPL/A  code  that  can  be  used  to  represent  the  'Analyte  Asset"  process 
definition.  Rut,  there  is  an  ’  Analysis.Typc"  TUPLE*,  which  shows  names  and  types  of  the  attributes  used  to  store 
the  evaluauon.forms*.  In  the  example,  the  *asseLlD"  number,  "assct.version"  number,  and  the 'evaluation  forms' 

themselves  are  stored.  The  INSERT"  "ENTRY*  specifies  the  procedure  call  used  to  store  the  "evaluation  forms'  with 
the  other  attribute  values.  The  attributes  sjMcified  in  an  "ENTRY*  may  not  be  the  entire  set  of  attributes  ^ified  in 
the  TUPLE';  foj  example,  the  object  code  attribute  may  not  need  to  be  suppUed  if  it  is  compiled  from  the  source  code. 
The  TRIGGER*  construct  specifies  that  'njn_metrics_coUecuon"  is  automatically  executed  when  the 
"cvaluaiion^forms"  are  insened  into  storage.  The  "run_metrics_collccuon'  proccduir.  collects  metric  data  on  the  asset 
and  adds  it  to  the  'evaluauon.forms.' 
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EXPERIMENT  IN  PROCESS  DEFINITION 

ADVANTAGES  AND  DISADVANTAGES  OF 

APPL/A  CODE 

Advantages: 

•  Medium  machine  e.xecutability 

•  Very  high  flexibility 

•  Very  high  completeness 

•  Medium  conciseness 

•  Medium  machine  analyzabiiity 

Disadvantages: 

•  Lo^  uiiderstandability 

This  chart  shows  the  advantages  and  disadvantages  of  using  APPUA  code  to  represent  a  process  definition,  as 
deicrmincd  from  our  experiment  Most  of  the  constructs  supplied  in  the  APPL/A  language  are  currently  executable  by 
a  machine  through  translation  of  the  code  to  Ada.  Machine  executability  is  one  characteristic  of  process  notations  that 
is  not  supported  by  many  other  notations,  due  to  the  complexity  invoiv^.  There  is  also  a  high  amount  of  flexibility 
in  the  APPL/A  language,  due  to  the  very  rich  set  of  constructs  available  from  the  Ada  language.  Also,  the  product 
management  needs  of  process  programming  were  carefully  analyzed  when  the  language  was  created,  to  ensure  that  the 
language  contained  the  complete  set  of  constructs  needed.  APPL/A  is  not  a  highly  concise  language,  due  to  the  large 
number  of  features  provided  for  flexibility  and  machine  executability.  Some  machine  analyzabilily  is  supported 
through  translation  to  Ada  and  analysis  of  the  Ada  code.  The  biggest  disadvantage  of  APPL/A  code  is  the  low  level  of 
granular'y  needed  to  specify  a  process  at  the  machine  enactment  level,  which  makes  the  language  less  understandable 
than  many  process  notations  at  higher  layers. 
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EXPERIMENT  IN  PROCESS  DEFINITION 

EXPERIMENT  COMPARISON  OF 
PROCESS  NOTATIONS 


( 


Language  Sunnort 

Characteristic 

DFD 

MVP-L  APPL/A 

Completeness 

Very  High 

Low 

High 

Very  High 

Conciseness 

Low 

High 

Very  High 

Medium 

Understandability 

High 

Very  High 

Medium 

Low 

Flexibility 

Very  High 

Low 

Medium 

Very  High 

Analyzability 

None 

Medium 

Executability 

None 

None 

None 

Medium 

This  chan  summarizes  the  comparison  of  process  notation  characteristics  described  in  the  previous  slides.  English  ii.  a 
complete,  flexible  ncution,  but  contains  no  support  for  machine  analyzability  or  exccuiability.  Data  Flow  Diagrams 
pFDs)  are  undersumdable,  but  do  not  contain  some  of  the  constructs  needed  to  completely  describe  a  process.  M  VP-L 
is  complete  and  concise,  but  docs  not  support  analyzability  or  executability.  APPL/A  suppons  some  analyzrb.iity  and 
exccuiability,  but  is  not  as  concise  or  understandable  as  the  other  notations. 
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EXPERIMENT  IN  PROCESS  DEHNITION 

EXPERIMENT  LESSONS  LEARNED  ABOUT 
PROCESS  DEFINITION 

•  Benefits 

-  Improve  understanding  of  a  process 

-  Enable  better  communication 

-  Discover  problems  in  original  English  process  description 

•  Costs 

-  Creating  process  descriptions  is  time  consuming 

1 

-  Retaining  understandability  at  level  of  detail  needed  for  enactment  is 

difficult 

-  Learning  curve  is  nontrivial 

-  Process  description  e.voerts  are  vital 

•  Suitability  of  experiment  notations 
-  Different  notations  for  different  uses 
•  Research  prototype  status  of  .MVP-L  and  APPL/A 

1 

This  slide  dcuiils  some  of  ihc  lessons  learned  about  process  definition  from  our  experiment  using  the  MVP-L  and 
APPL/A  process  represeniauon  languages.  The  benefits  achieved  by  defining  our  process  included  an  improved 
understanding  of  the  overall  process  and  all  of  the  steps  that  were  involved.  This  understanding  helped  us  to  better 
organize  the  process  definition.  Writing  down  the  process  definition  in  English,  graphical  notations,  and  MVP-L  made 
it  much  easier  to  communicate  the  process  steps  widi  those  who  were  rot  familiar  with  the  Certification  of  Reusable 
Assets.  Another  benefit  of  representing  our  process  in  graphical  notations  and  MVP-L  was  that  we  discovered  required 
information  that  was  unintenuorally  left  out  of  our  original  English  desenpuon  of  the  process.  We  are  now'  weii  into 
the  program  layer  in  our  e.xpenment  and  hope  to  soon  have  machine-executable  APPL/A  code  so  that  we  can  determine 
the  benefits  of  machine  exccutability. 

There  were  many  costs  associated  with  creating  our  process  definitions.  We  found  that  creating  process  definitions  was 
time  consuming  and  more  difficult  than  we  had  expected.  We  were  surprised  at  the  large  amount  of  text  needed  to 
represent  a  process  formally.  At  the  level  of  detail  needed  to  represent  a  process  defimuon  in  a  notation  such  as 
APPL/.A  for  miachine  enactment,  it  was  difficult  to  retain  undersiandabiliiy  of  the  code  produced.  We  also  spent  more 
ume  learning  about  process  defimuon  and  programming  than  we  had  expected.  We  found  that  process  definition  experts 
■were  vital.  We  did  net  have  experts  available  at  the  beginning  of  cur  task,  but  adding  experts  to  the  expenment  team 
near  t.hc  end.  These  experts  were  able  to  produce  process  dcfiniiions  in  a  much  shorter  time  than  the  novices.  As 
.,.~.j'wr.  cn  irc  previous  chan,  we  found  ihat  difrc.-on  process  notations  arc  suitable  for  different  uses.  Wc  also  found 
mat.  due  to  the  research  proioiypc  s'-nius  of  s' VP-L  and  APPU.a  i*';,-;  was  a  lack  of  user  d:.euincr.L;iinn  end  -jo'. 
suppc.T-  Other  process  notaiions.  including  ihc  some  used  :r  the  ST.ARS  '91  dcmonstraiicits,  are  not  research 
prototypes,  xnd  would  not  have  presented  many  of  these  diffieulues. 
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EXPERIMENT  IN  PROCESS  DEHNITION 

EXPERIMENT  CONCLUSIONS 


•  Process  definition  can  be  utilized  to  gain  insight  into  a  software  pf'ccess 

•  Appropriate  level  of  detail  must  be  used  to  maximize  benefits  while 

keeping  costs  affordable 

•  Process  definition  training  is  necessary 

•  Formal  process  definition  may  follow  all  or  part  of  conventional  life 

cycle 

-  English  for  requirements  analysis 
•  Graphical  notation  for  requirements  analysis  and  design 

-  MVP-L  is  good  for  textual  high  and  low  level  design 

-  APPL/A  for  code  phase 

-  Testing  of  all  notations  is  necessary 

•  Greatest  benefits  achieved  at  lowest  costs  through  tailoring  and  reuse  of 

experience-tested  process  definitions 

Frocta  0<CiAttuj*tKL^t^yC20 

- -  ^ 


In  conclusion,  in  our  wpcrimcm  we  tound  vhai  process  dcfiniiion  can  be  of  great  bcncni  for  gaining  insight  into  a 
software  process  but  it  must  be  used  with  care.  The  appropriate  level  of  abstraction  must  be  used  that  matches  the 
needs  of  the  specific  organization,  to  maximize  the  benefits  of  process  definition  while  keeping  costs  within  the  project 
budget  The  cost/benefit  tradeoff  of  defining  a  process  is  similar  to  the  tradeoff  faced  when  deciding  whether  lo  use 
Case  lool  technology  on  a  project  'Tic  use  of  both  of  these  methods  requires  more  money  and  time  spent  in  the  early 
stages  of  the  software  developn.ciit  p  jcess  for  tool  purchase  and  execution  of  the  methodology,  but  a  bcuer  quality 
software  product  is  usually  produced.  Training  in  process  definition  greatly  improves  the  productivity  of  engineers 
if'®  process.  In  many  respects,  process  definition  docs  follows  the  same  steps  as  the  software  development 
lifecycle,  of  requirements  analysis,  high-level  design,  low-level  desigrt  coding,  testing,  operation,  and  maintenance. 
Depending  on  the  level  of  detail  necessary  and  the  laycr<$)  that  are  addressed,  the  coding  step  may  be  skipped.  It  is 
important  to  note  that  testing  and  maintenance  are  necessary  for  a  process  definition  represented  in  any  notation,  in 
order  for  the  process  to  evolve  and  improve.  Various  notations  are  appropriate  at  different  steps  in  the  definition  of  the 
process,  depending  on  the  project  goals.  However,  we  have  found  that  great  benefits  can  be  achieved  at  a  low  cost 
through  the  tailoring  and  reuse  of  experience-tested  process  definitions.  We  invite  the  audience  to  read  our  lessons 
learned  and  guidelines  for  process  dcfiiiiuon.  and  \o  apply  them  to  describe  theu-  software  processes. 
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ENACTING  THE  SOFTWARE  PROCESS 

OBJECTIVES 


To  have  vou  walk  awav  from  this  talk  with  a  basic  understanding  of: 

•  What  process  enactment  is 

•  Why  you  should  want  automated  support  for  process  enactment 

•  What  work  STARS  has  performed  in  providing  automated  support 
for  process  enactment 


ubjeo  of  process  enactment  is  a  difiEcult  subject  to  co>-er  in  detail  under  a  tbirty  minute  dme  conscamL  Therefore. 
Tresentatkm  wiU  outline  the  basic  ccocepts  of  process  enactment  and  automated  process  enactment  support,  and  will 
ify  some  of  the  benefus  to  be  derived  by  providing  autcanaied  support  for  enacting  the  software  process.  This  Icnowl- 
will  enable  you  to  understand  how  software  engineering  enviionroezus  and  technology  to  automate  process  enactment 
x  applied  to  help  software  development  teams  foQow  a  defined  process  and  facibiaie  software  process  improvement 
in  an  organuaooo. 

Important  areas  that  will  not  be  covered  in  this  preseniaoon  are: 

1)  Process  enactment  technologies  being  investigated  by  STARS.  The  conraa  deliverable  reports  produced  by  the 
STARS  prune  contractors  are  good  sources  for  this  information. 

2)  Planning  for  automated  process  enactment  suppon  -  how  to  talce  3  defmed  process  and  implzroeni  it  to  supper, 
proc^  caacnneitt.  The  contraa  deliverables  produced  by  the  IBM  team's  Cleanroom  Software  Process  Case  Sutfy 
provide  an  example  of  taltmg  a  defined  process,  the  Cleanroom  Engineering  Software  Devetopmeni  Process  and  im¬ 
plementing  It  u)  a  tool  called  the  KI  Shell  A  similar  example  can  be  found  m  Boeing  team's  woti  on  policy  enact¬ 
ment.  m  which  control  point  enactment  mechanisms  were  used  to  implement  the  case  study  prepared  for  the  Suah 
Iruemaaonal  Software  Process  Vi'orkshop. 

We  irge  you  to  vtsa  the  CBM  and  Boeing  team's  process  enactment  technology  demonstrations  at  STARS  '91  lo  view  first 
hand,  the  STARS  technology  point  solunons  to  provide  automaied  suj^xm  for  enacting  an  organizanon’s  process. 
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PROCESS 

PROCESS  DRIVEN  DEVELOPMENT 


O 

This  chan  Ulustraies  a^)eas  of  process  <tnvea  dcvdopmeui  from  project  and  process  plannins,  process  definitxjn,  and  proc¬ 
ess  implementaDOD  (O  process  enacnnent  {execudon  or  performance).  Support  for  enacting  ih*  software  process,  whether 
autonuied  or  not,  deals  with  supporting  an  enactment  agent  to: 

•  Follow  (use)  a  defined  software  process 

•  Capture  raeasurements  to  permit  process  performance  analysis  and  unprovemcm 

•  Manage  process  state  and  history  data  to  permit  management  reporting  on  the  state  of  process  and  project  acQviues. 

Before  processes  can  be  scheduled  and  installed,  they  must  be  planned,  modeled,  implemented  and  tested  Planning  for 
process  enactmeat  may  require  the  ability  to  siniiilac  processes  pnor  to  iheu  unplcmeniatit  n,  thus  automated  process  en- 
aconem  support  may  also  serve  a  role  m  testing  process  definitions. 

This  prescntahoi)  will  focus  on  process  enactment  support  m  the  "etecunon"  area  of  the  c.*ian,  where  whether  we  ptoMde 
automated  support  for  enacting  the  process  or  oot,  our  focus  is  on  support  for  the  execution  or  performance  of  a  defined 
process 
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ENACTING  THE  SOFTWARE  PROCESS 

OUTLINE 


•  Objectives  for  the  Talk 

•  Process  Driven  Development 

•  Whai  Is  Process  Enactment? 

•  Automation  Envelope  for  Supporting  Software  Process  Enactment 

•  Levels  of  Process  Enactntent  Support 

•  Simple  Software  Module  Speciftcation  Process 

•  Simple  Software  Module  Specification  Process  (SADT  DaU  Row  RepresenUtion) 

•  Simple  Software  Module  Spcciflcation  Process  (Informal  Noution  Representation) 

•  Level  "A/B/C/D/E”  Support  for  Process  Enactment 

•  Why  Should  You  Want  Automated  Support  for  Process  Enactment? 

•  STARS  Process  Enactment  Work 

•  Conclusions 


84 


ENACTING  THE  SOFTWARE  PROCESS 

WHAT  IS  PROCESS  ENACTMENT? 


The  executioni performance  of  process  descriptions  by  an  agent,  where: 

•  The  agent  supports,  guides,  checks,  and/or  enforces  a  defined  process 

Defined  proc.  .  .t  are  enactable  exhibit  these  characteristics: 

•  Entry  criteria 

•  Process  steps  and  process  states 

•  Validation  and  exit  criteria 

•  Enactment  agents 

•  Stimuli  (data/control)  /  required  data  resources 

•  Responses  (data/control)  /  resultant  artifacts 

Esmbhi  M  i*wwiiiTniiVC3 


Protess  enacnnem  is  the  execuaon  or  perfomance  of  pnxess  descriptions  by  an  agent,  where  the  agent  enacting  the  process 
is  a  human  or  a  computer  system  that  is  provided  with  sufficient  knowledge. 

Regardles.s  of  the  agem  of  enactment,  the  agent’s  pu^xise  is  to  support,  guide,  check,  and  enforce  if  necessary,  the  following 
characiensiics  of  a  defined  process: 

-  Defined  entry  criteria  -  the  conditions  that  must  be  met,  before  the  process  can  be  enacted 

-  A  set  of  process  steps,  and  the  identtfication  of  internal  process  states  and  st^te  transitioa  conditions 

Validation  and  exit  enteria  -  that  must  be  met  before  the  results  of  the  process  can  be 
passed  to  other  processes 

-  One  or  more  agents  to  enaa  the  process 
Stimuli  (data/control) 


Responses  (data/control)  /  Resultant  artifacts. 


ENACTING  THE  SOFTWARE  PROCESS 

AUTOMATION  ENVELOPE  FOR  SUPPORT 
ING  SOFTWA.iE  PROCESS  ENACTMENT 


The  software  devetopinem  process  for  an  organization  represents  a  system  of  processes  put  into  place  to  meet  the  organiza¬ 
tion’s  or  project’s  objectives  of  developing  computer  software.  As  in  other  disciplines,  the  ability  to  provide  automated  sup¬ 
port  depends  largely  on  bow  «  ell  the  processes  to  be  automated  are  understood  and  on  whether  the  computer  systems  can  be 
provided  with  sufficient  knowledge  and  capability  to  perform  the  processes. 

Accounting  systems  existed  thousands  of  years  before  the  advent  of  the  first  calculator.  When  computers  came  of  age,  how¬ 
ever,  accounting  functions  were  analyzed  for  potential  automation,  and  subsequently  many  bookkeeping  systems  were  auto¬ 
mated.  At  the  advent  of  CThne  transactioa  processing,  some  of  these  bookkeeping  systems  were  replaced  and  other 
transaction-OTieoxed  bookke^ing  applicaiions  were  automated.  At  the  advent  of  expert  systems  technology,  accounting 
functions  were  analyzed  to  see  what  accounting  processes  this  new  technology  could  automate.  Financial  statement  prepara¬ 
tion  was  identified  as  a  target  for  autoroahoo,  when  it  was  felt  that  an  expert  system  could  be  developed  to  automate  ’’rou¬ 
tine”  statement  preparation  ia<v<  so  thar  humans  could  be  left  to  produce  the  complicated  statements  that  current  expert 
systems  just  could  not  hope  to  prepare.  An  accounting  system  for  an  organization  is  still  a  complete  system  of  methods  and 
prxccss  for  performing  bookkeeping  and  financial  statement  preparation.  Auiomabon  has  only  redtsorbutsd  how  book¬ 
keepers  and  accountants  time  is  spent  in  supporting  the  accounting  system. 

This  same  analogy  hoids  for  developing  s'.'stems  to  provide  aumroaied  support  for  enacting  an  organization's  software  de¬ 
velopment  process.  We  hope  to  redistribuie  bow  strfrware  development  professional’s  time  will  be  spent  in  developing  soft¬ 
ware,  perraining  software  eagineeis  to  concentrating  on  the  creative  aspects  of  software  development,  while  still  me~ung 
our  process  measurement  and  imi^vement,  and  produa  quabey  objeenves. 


There  are  two  important  aspects  to  consider  with  respect  to  providing  auicmaied  suppor  for  enacting  the  software  process, 
namely  (1)  our  ability  to  automate  manual  steps  and  (2)  how  our  automation  ability  may  change  the  jjrocess  itself. 


ENACTING  THE  SOFTWARE  PROCESS 

LEVELS  OF  PROCESS  ENACTMENT 
SUPPORT 

Level  A)  Manual-based  process  support 
-  Process  by  the  manual 

Level  B)  Computer-assisted  manual-based  process  support  - 
-  Process  manual  online 

-  same  as  A  + 

Level  C)  Passive  automated  process  support  -  same  as  B  -f 

-  Simple  work  flow  automation 

-  Process  advice  tied  to  tool  invocation 

Level  D)  Interactive  passive  process  support  -  capabilities  of  C-t- 

-  Process-supported  SEE  (accessing  tools  is  unit  of  work) 

-  Computer-based  models  of  how  tools  and  data  relate  to  processes 

-  Unobtrusive  data  collection  and  management  reporting 

Level  E)  Active  process  support  -  same  as  D  -t- 

-  Process-driven  SEE  (accessing  process  tasks  is  unit  of  work) 

-  Unobtrusive  management  of  all  project  acti\ities  and  artifacts 

produced  i— „  ^ 

This  chan  characterizes  five  levels  of  suppon  for  enacting  software  processes.  The  purpose  of  this  chan  is  not  to  establish  i 
ranking  system  of  process  enactment  support,  but  to  identify  levels  with  our  ability  to  extend  the  ’’automation 

envelope"  in  providing  process  enactment  suppon."  Given  today’s  state  of  technology  in  software  process  managemetii,  the 
entry  criterion  is  a  high  one  -  an  organizabon  must  have  a  "defined"  process,  as  having  a  "defined"  process  is  a  prxondi* 
bon  to  plan  fw  any  automated  process  enactment  support. 

Levels  "B"  and  "C"  relate  to  compuier-assisied  process  enactment  suppon  where  the  organizabon  has  a  defined  process  for 
performing  software  development,  but  does  so  using  tools  that  provide  limited  integranoa 

Levels  ”D"  and  "E"  relate  to  computer-assisted  process  enactment  suppon  where  the  organizabon  has  invested  in  a  modem 
software  engineering  environment  and  wishes  to  provide  finer-grained  process  suppon  for  enacting  the  software  process  and 
for  automatically  performing  necessary  work  steps. 

The  major  difference  between  level  "D"  and  "E"  is  how  process  is  presented  to  the  user  and  how  process  suppon  is  planned. 
At  level  D,  the  main  unit  of  work  is  the  invocabon  of  tools,  where  finer-grained  process  enactment  suppon  can  be  provided 
than  at  level  C.  The  mteni  of  level  H)"  process  enactment  automanon  is  lo  bnng  process  aenviues  and  advice  closer  to  us¬ 
ers  through  their  use  of  nols  instantiated  into  the  software  engineering  environmenL  At  level  "E,"  tlK  proctss  for  a  project 
is  a  wdl-planned  and  designed  system,  where  the  unit  of  work  in  the  software  engineering  environment  is  through  mvoking 
process  steps,  where  tools  and  data  are  made  available  for  performing  each  process  step. 
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ENACTING  THE  SOFTWARE  PROCESS 

SIMPLE  SOFTWARE  MODULE 
SPECIFICATION  PROCESS 


PAl)  Assign  SW_Module_Specification  Task 

PA2)  Prepare  SW_Mo<lule_Specification 

PA3)  Conduct  team  review  of  SW_Module_Specification 

PA4)  Review  Team_Review_Results  and  accept  or  reject 
SW_Mod  ule_S  peci  fication 

pwiiiu/vci 


This  represents  a  sunple  process  for  preparing  Software  Module  Spec^cadons.  As  humans,  we  can  view  a  pitxess  like  this 
and  have  a  good  understanding  of  what  is  involved  in  following  it.  It  does  not,  however,  meet  our  (definition  of  an  ertac- 
table  process. 


88 


EXACTING  THE  SOFTWARE  PROCESS 

SAV  MODULE  SPECIFICATION  PROCESS 


New  fncT?metn  I 

Incrtnxrt 
Resources 
Aisipicd 


PAl: 

AUlgD  S/W 

Moduie 

Specifotjoft 


Assigned  S.V 
SproriuuoQ 


CM 

SEPG 

1 

PAl 

Prepwt  S/^ 

Module 

Spoaficaucn 


S/W  Module  Spcciftcauon  Monc  Form 


I  S/W  Module  Spccircsuon 
I  Ready  for  Team  Review 


S'W  Module  Spec  Team  Review  Meuic  Form 


Team  RtvK»  Moderator  Scnpi  ♦ 

Reviewed  S/W  Moduic  Specii'icauoo  ♦ 

Chockious)  for  S/W  Module  Spocifrotioofl  pcrrrnew 
icam  member) 

-  »  Review  Team  Arubos 


PA4 

Mgi  Review  of 
S/W  Module 
Spec  k 

Review  Team 

Conunejut 


Accecred  S/W  Module  Spccificauon 


Reiected  S  W  Module  Spccincauon 


This  represen uiioD  of  our  simple  process  for  preparing  Software  Module  Spec^auons  iUu.  sates  resources  rf>;uuBd  for  the 
process  sieos  and  am^acts  produced  From  this  view,  we  can  beoer  understand  bow  the  process  steps  relate  to  each  other 
by  examining  the  data  flow.  This  process  description  still  docs  not  meet  our  definition  of  an  enactabie  process,  however. 
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ENACTING  THE  SOFTWARE  PROCESS 

SOFTWARE  MODULE  SPECIFICATION 

PROCESS 


Refer  to  VG27  -  PA2;  Prepare  SAV  Module  Specification  Task 
Description  meets  criteria  for  an  enactable  process  and: 

•  Process  steps  are  defined  as  an  algorithm 

•  Process  steps  can  be  assessed  for  automation  potential 

Candidate  activities  for  automation: 

•  Setting  state  attributes 

•  Completing  metrics  forms 

•  Managing  calendar  coordination 

•  Notifying  configuration  management  tools  of  artifact  state 

•  Updating  project  management  toots  based  on  process  state  data 

Eait  tM  So4r»M  PiaMi/EftVClO 


A  more  (Jeoiled  process  description  can  be  found  on  charts  VG23a  through  VG30.  If  you  refer  to  chan  VG27  ~PA2:  Pre¬ 
part  Module  Spec^caaon  Task  you  will  observe  that  this  process  meets  our  criteria  for  an  enactable  process.  In  addi- 
uon,  the  process  is  defined  as  an  algorithm.  Further,  because  we  have  taken  a  more  formal  approach  to  describing  the  steps 
of  our  process,  these  steps  can  be  more  easily  assessed  for  their  automation  potenoal. 

We  have  identihed  some  acdvrbes  that  ate  candidates  for  autcmaaoa 

-  Process  state  attributes  could  be  automatically  set  at  the  compleuon  of  process  steps 

Asststance  for  completing  metrics  forms  could  be  provided,  where  process  metrics  could  be  captured  as  the  work 
was  performed  and  automatically  included  on  the  form 

Assistance  fee  managing  calendar  coordinaticn  could  be  provided,  depending  on  ability  of  the  tooi(s)  selected  to  support 
calendar  management 

Aissistance  ice  communicating  the  state  of  artifacts  to  a  configuration  management  tool 

-  Assistance  for  updaung  project  management  tools,  based  on  changes  m  selected  process  states,  c.g.,  update  the  project 
management  sysmm  /tatahaw  when  a  milestone  has  been  reached 
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ENACTING  THE  SOFTWARE  PROCESS 

LEVEL  “A’’  SUPPORT  FOR  PROCESS 
ENACTMENT 


Manual  process  enactment  support 

•  Assumptions 

-  No  automated  process  enactment  support 

-  Manager  has  PC-based  project  management  system 

•  Summary 

-  Automation  was  not  required  to  enact  the  process 

-  Manual  acquisition  and  completion  of  all  forms  were  required 

-  Manual  interpretation  and  codification  of  metrics  forms  were 
required 

-  Project  management  system  was  manually  updated  by  the  software 
increment  manager 

EMoaif  Oh  1 1 


This  chan  charxisrizes  what  it  would  be  like  to  manually  enact  our  example  process. 

The  following  are  assumed: 

•  The  process  is  manually  enacted. 

•  The  software  increment  manager  uses  his  or  her  favorite  PC-based  project  management  system  to  plan  and  manage 
the  software  incremcnL 

Automation  was  not  required  to  enact  the  process.  Therefore,  none  of  the  beneSis  of  automation  were  ^-ealired.  All  re¬ 
quired  forms  needed  to  be  manually  prepared.  Paper-based  fonns  were  submioed  to  the  SEPG  for  manual  interpretauc.'i 
and  codification.  The  project  management  system  needed  to  be  manually  updated  by  the  software  inoement  manager. 


ENACTING  THE  SOFTW'ARE  PROCESS 

LEVEL  “A”  SUPPORT  FOR  PROCESS 
ENACTMENT  (CONTINUED) 

Manual  process  enactment  support  (continued) 

•  Comments 

-  Process  compliance  was  on  the  honor  system 

-  If  process  not  consistently  followed,  process  data  collected  may  be 
biased 

-  Foils  ideas  of  improving  process  through  measurement 

-  Metrics  forms  completion  and  processing 

-  Small  project  /  Small  problem 

-  Big  project  /  big  problem 

-  Problems  can  scale  up 

tmmamt  iM  Jatam  hniwi  i£ll/VCa 


Compliance  to  following  our  example  process  was  on  tl«  "honor  system.”  This  is  scceptable  if  software  development  per¬ 
sonnel  are  trained  in  the  processes  they  are  expected  to  follow.  However,  if  the  pnx'esses  are  not  consistently  followed, 
data  collected  on  the  process  (process  and  product  metrics)  will  potentially  be  biased.  This  bias  foils  the  concept  of  process 
anal)'sis  and  improvement  through  meastnemenL 

Rega,  ding  the  metrics  forms  complebon  and  processing,  we  have  examined  a  number  of  paper-based  metne  coUecuon  sys¬ 
tems  They  tell  us  that  they  are  probably  only  going  to  be  a  small  problem  for  a  small  project.  However,  small  problems 
can  ;£ale  up  to  become  big  problems  in  big  projects  and  depending  on  the  size  and  organization  of  the  project,  problems 
r.'  ay  not  necessarily  scale  linearly. 

Note;  We  view  processes  as  being  flexibly  defined  but  rigwously  enforced.  This  means  diat  processes  should  not  be  de¬ 
signed  to  "contTor  the  sofTwre  engineer’s  every  move.  It  simply  means  that  along  with  the  creative  steps  of  software  de- 
veloptuent,  there  are  process  steps  to  ensure  the  quality  of  the  products  we  produce  and  to  collect  data  to  determme  how  we 
can  make  our  processes  for  developing  soft  .'/are  better.  The  ultimate  goal  is  to  minimize  Tiusy  work”  for  software  engi¬ 
neers,  providing  them  more  ome  to  spena  on  the  creative  acoviues  of  software  engineering. 
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ENACTING  THE  SOFTWARE  PROCESS 

LEVEL  “B”  SUPPORT  FOR  PROCESS 
_  ENACTMENT  _ 


Computer-assisted,  manual-based  process  enactment  support 

•  Summary 

-  Process  was  enacted  manually,  without  computer-based  assistance 

-  Manual  interpretation  and  codification  of  metrics  forms  were 
required 

-  Project  management  system  was  manually  updated  by  the  software 
increment  manager 

•  Benefits  of  level  “B”  process  enactment  support 

-  Process  manual  available  online  -  but  process  enactment  same  as 
level  “A” 

-  Benefits  of  automated  support  not  realized  at  level  “B” 


All  of  the  conunents  that  applied  to  level  ”A”  basically  apply  to  level  ”B”  as  well  The  big  iiSmacc  is  that  the  process 
software  developers  are  expected  to  follow  is  available  ooline.  Fonns  that  the  process  requires  could  probably  be  extracted 
from  the  online  process,  and  thus  the  forms  could  be  completed  using  a  text  editor  or  word  processor.  However,  these 
forms  would  still  have  to  be  manually  processed. 


1 
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ENACTING  THE  SOFTWARE  PROCESS 

LEVEL  “C”  SUPPORT  FOR  PROCESS 
ENACTMENT 


Passive  automated  process  enactment  support 

•  Summary 

-  Environment  for  implementing  levels  “B”  and  “C”  process 
enactment  support  is  POSIX  (UNIX/AIX) 

-  Tool-to-tool  control  integration  is  through  shell  scripts 

-  Data  integration  is  through  special  purpose  tool-to-tool  data 
bridges 

•  Potential  benefits  of  level  “C”  process  enactment  support: 

>  Automated  enactment  support  from  shell  scripts: 

-  Assist  in  online  data  collection  and  forms  completion 
>  Display  process  guidance  when  tools  are  invoked 

SaattBi  ilM  SiO»—  PwMa/Ca/VCU 


Codipuhng  environfflents  to  support  level  and  level  "C  are  typically  POSDC-compliaot  environmems  such  as  AlX  or 
UNIX.  At  level  ”C.”  only  coarse-grained  process  siq>s  can  easily  be  iroplemented  to  provide  suppon  for  enacting  the  soft¬ 
ware  process.  This  gtantilatity  is  deutmined  by  the  tools  selected  and  the  program  integration  capability  they  affod. 

At  level  "C.”  potential  benefits  can  be  realized  firom  providing  automated  process  enactment  support  Support  for  complet¬ 
ing  the  forms  required  by  the  process  can  be  implemented  and  tied  into  shell  scripts  to  appear  either  before  or  after  a  tool  is 
invoked.  Process  guidance  could  be  provided  upon  tool  invocation.  Further,  rudimentary  process  meihcs  could  be  collected 
from  shell  scripts,  such  as  elapsed  tool  use  time  and  elapsed  time  on  system,  associated  with  a  particular  work  item.  Metrics 
forms  could  be  panially  completed  auiomaticaUy.  but  would  still  rely  on  the  software  engineer  to  manually  complete  the 
form,  based  on  the  notes  and  records  he/she  kept. 


Projea  management  dau  on  activities  and  milestones  still  require  manual  updating  by  the  software  inciemeni  manager. 
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ENACTING  THE  SOFITVARE  PROCESS 

LEVEL  “C”  SUPPORT  FOR  PROCESS 
ENACTMENT  (CONTINUED) 


Passive  automated  process  enactment  support  (continued) 

•  Potential  benefits  of  level  “C”  process  enactment  support  (continued): 

-  Automated  enactment  support  from  shell  scripts  (continued): 

-  Automatically  collect  rudimentary  measurements 

-  Elapsed  tool  use  time 

-  Elapsed  time  on  system 

-  Partial  manual  completion  of  metrics  forms  as  required 

-  Project  management  system  was  manually  updated  by  the  software 
increment  manager 
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ENACTING  THE  SOFTWARE  PROCESS 

LEVEL  “D/E”  SUPPORT  FOR  PROCESS 
ENACTMENT 


Interactive  passive  and  active  automated  process  enactment  support 
•  Assumptions 

-  Tools  integrated  into  the  SEE  and  the  processes  they  support 

-  We  understand: 

-  Process  tasks  and  their  preconditions  for  enactment 

-  State 

-  Available  data 

-  Project  artifacts  and  the  processes  that  create,  maintain  and 
employ  them 

-  Process,  product  and  project  metrics  and  the  processes  to  collect, 
analyze  and  report  them 


Fm—n  Pwii/tWVCI* 


Ai  kvels  "D"  and  "E,"  wc  assume  that  process  enactment  support  will  be  integrated  with  a  modem  software  engineering 
environment  where  processes  are  defined  to  the  SEE,  as  well  as  the  tools  and  data  required  to  support  them.  Process  eaaa 
ment  support  applications  can  be  provided  with  knowledge  ct 

•  The  preconditions  necessary  for  enacting  a  process  step,  and  the  rules  for  transitioning  between  process  states 

•  Project  artifacts  and  the  processes  that  can  create,  maintam.  manipulate  and/or  employ  them 

•  Process,  product,  and  projea  metrics  and  the  processes  that  need  to  coOect,  analyze,  and  report  them. 
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ENACTING  THE  SOFTSVARE  PROCESS 

LEVEL  “D”  SUPPORT  FOR  PROCESS 
ENACTMENT 


Interactive  passive  automated  process  enactment  support 
Potential  benefits  (process-supported  SEE): 

•  Stronger  tie  between  process  and  SEE  use 

-  Finer  grained  process/tooL^data  integration  is  possible 

•  Forms  on-line  and  presented  at  selected  process  steps 

-  Unobtrusively  collect  data  and  measurements 

-  Automate  partial/total  forms  completion 

-  Process  guidance  as  needed 

•  Greater  potential  for  task  automation 

-  Tasks  could  be  semi-automated,  based  on  menu  responses 

-  Tasks  could  be  spawned  to  perform  other  tasks 

-Update  project  management  system 
-Initiate  other  work  steps 


Among  the  potential  benefits,  at  levels  ”D"  and  "E,"  we  have  the  ability  to  provide  a  stronger  tie  between  the  process  enact¬ 
ment  support  lool(s)  and  the  SEE.  At  level  "D."  we  are  preparing  the  proeest-supported  SEE, 

With  the  proceu-supported  SEE  we  want  to  provide  finer  grained  processAooI/data  integration  to  provide: 

•  Process  support  where  process  support  is  needed,  not  just  where  it  is  convenient  to  implement; 

•  Better  automated  support  for  metrics  collection  and  required  forms  completion.  For  example,  at  level  ’*C  we  could 

only  capture  data  on  elapsed  time  using  a  tool  or  elapsed  time  working  on  a  system  for  a  given  work  item.  At  level 
HD”  we  can  ct^ect  metrics  and  data  with  a  process  step,  based  on  the  results  of  the  process  stq>.  Conse¬ 

quently,  some  of  the  process  metrics  that  we  required  the  software  engineer  to  manually  maintain  can  now  be  totally 
captured  automatically,  relieving  the  requirement  to  complete  process  metrics  forms  entirely; 

•  Greater  potential  for  fade  automation  where  casks  could  be  semi-auioraaied.  based  on  human  responses  to  menus, 
eic..and  where  can  be  automatically  spawned  to  perfonn  other  tasks,  such  as  the  automatic  updating  of  a  pro- 
jea  management  system  when  a  mdesione  has  been  reached. 


97 


ENACTING  THE  SOFTWARE  PROCESS 

LEVEL  “E”  SUPPORT  FOR  PROCESS 
_ ENACTMENT _ _ 


Active  process  enactment  support 
Potentia]  benefits  (process-driven  SEE): 

•  SEE  use  is  through  process 

-  Processes  are  accessed 

-  Tools  are  invoked  and  data  is  made  available  through  process  tasks 

-  Support  for  following  the  process  is  unobtrusive 

-  Work  activities  are  properly  staged 

•  Task  automation 

-  Housekeeping  activities  are  automated  to  the  extent  possible 

-  More  time  made  available  for  creative  activities  of  software 
development 

-  Forms  completion  and  processing  problems  not  eliminated,  but 
reduced 

btmmm  •*  Satax  fwiii  lU/VCIt 


Ai  level  "E”  our  focus  is  to  mske  SEE  users  process  users,  where  the  SEE  is  used  through  the  process.  Al  this  level,  we  ate 
prqwring  the  proees$-iirntn  SEE. 

With  the  process-driven  SEE : 

•  Process  tasks  are  accessed,  not  tools.  Tools  are  invoked  and  data  is  made  available  through  the  invocation  of  process 
tasks. 

•  Process  suppon  is  unobtrusive.  Users  sdD  do  the  same  work  they  did  before  and  probably  use  the  same  tools.  The 
real  difference  is  their  method  of  invocation  and  the  autotnadc  housekeeping  being  petfonned. 

•  Process  tasks  ate  picperty  staged  to  present  tasks  to  users  when  the  cooditioas  for  perfonning  the  tasks  have  been 
met. 

For  task  .uitonuuion.  housekeeping  activioes,  such  as  metric  and  data  collection  me  automated  to  the  extent  possible.  Fur¬ 
ther,  tasks  not  requiring  human  invocatioo  where  the  necessary  precoodmons  have  been  met.  can  be  automatically  enacted. 
Although  forms  conipletioo  and  forms  processing  problons  wiU  prooMbly  not  be  locaUy  eliminated,  the  effort  required  to 
complete  and  process  them  will  be  reduced.  With  this  automation  we  hope  to  achieve  our  goals  of  nuking  more  time  avail¬ 
able  to  the  software  engineer  to  concensxe  on  the  creative  activities  of  software  development,  while  nnobmuively  collect¬ 
ing  meoics  horn  a  consistently  applied  process  to  facilitate  process  analysis  and  improvement. 
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ENACTING  THE  SOFTWARE  PROCESS 

LEVEL  “E”  SUPPORT  FOR  PROCESS 
ENACTMENT  (CONTINUED) 


Active  process  enactment  support  (continued) 

Potential  benefits  (process-driven  SEE)  (continued): 

•  The  larger  the  project,  the  greater  the  need  for  automated  process 
enactment  support 

-  Manual  process  enactment  cannot  scale  up,  automated  process 
enactment  support  can 


The  larger  die  project,  the  greater  the  need  for  automated  process  enactment  support.  Problems  realized  from  manual  proc 
ess  enactment  can  scale  up.  Automated  process  enactment  stqrport  is  required  to  address  those  problems. 


ENACTING  THE  SOFTWARE  PROCESS 

WHY  SHOULD  YOU  WANT  AUTOMATED 
PROCESS  EN  ACTMENT  SUPPORT? 


•  The  cost  of  no  support  for  process  enactment  versus  automated 
process  enactment 

-  Organizations  that  have  the  ability  to  quantitatively  analyze  and 
improve  their  process  for  developing  software  will  achieve  a 
competitive  advantage 

•  Collecting  and  completing  measurements  on  software  development 
activities  is  equated  to  “important”  busy  work 

-  Let  computers  assume  as  much  busywork  and  housekeeping  as 
possible 

-  Free  software  developers  to  concentrate  on  the  creative  aspects  of 
software  development 

-  Process  improvement  depends  heavily  on  the  results  collected 

laiiH  m  hwnWtWVO 
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ENACTING  THE  SOFTWARE  PROCESS 

WHY  SHOULD  YOU  WANT  AUTOMATED 
PROCESS  ENACTMENT  SUPPORT?  (ID 


•  I  can  have  process  improvement  without  process  enactment  support! 

-  True,  but  the  activity  will  be  very  labor  intensive. 

-  IBM  Houston  *‘On-Board  Shuttle  Program”  views  process 
automation  mandatory  to  reduce  its  process  management  costs 

-  Automated  support  can  help  ensure  process  “consistency” 

-  Process  consistency  helps  assure  more  reliable  measurement 

-  Reliable  measurements  is  one  of  the  keys  to  making  statistical 
quality  control  work 

•  Automated  support  for  process  enactment  can  help  keep  projects  in 
‘intellectual  control” 

-  Large  numbers  of  tasks  to  assign  and  track 

-  Need  automated  task  status  reporting  to  help  monitor  task  needs 

-  Task  status  reporting  could  be  made  a  step  in  selected  process  tasks 
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ENACTING  THE  SOFTWARE  PROCESS 

STARS  PROCESS  ENACTMENT  WORK 

What  has  STARS  done  in  the  area  of  software  process  enactment 
support? 

•  Boeing/Honeyweil  Team:  Policy  representation  prototype  using 
control  point  process  enactment  mechanisms 

-  Action  item  browser  (human  agent  interface  to  process  enactment) 

•  IBM/SET/UES  Team:  The  Cleanroom  Engineering  Process  Assistant 

-  A  Kl-^hell  Process  System  application 

-  Artifact  of  IBM’s  Cleanroom  Software  Process  Case  Study 

-  CEPA  is  a  system  to  provide  assistance  in  enacting  the  Cleanroom 
Engineering  Software  Development  Process 

What  can  be  seen  here  at  STARS  ’91?  —  The  Action  Item  Browser 
interface  and  CEPA! 
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ENACTING  THE  SOFTWARE  PROCESS 

CONCLUSIONS 


•  Organizational  process  maturity  will  differentiate  which  software 
producers  can  supply  high  quality  products  and  services  to  their 
government  customers  in  the  coming  decade  (SEl  mandate) 

•  An  evolutionary,  incremental,  reuse-oriented,  prototyping-based 
(Megaprogramming)  process  mociel  allows  large  programs  to  deal 
with  complex,  software  intensive  systems  more  effectively  than 
previous  approached  (DARPA  mandate) 

•  Automated  process  enactment  support  carries  our  process  planning 
work  into  predictable  process  “execution’'  or  “performance”  and 
controlled  process  evolution 

•  Automated  process  enactment  support  is  necessary  to  achieve  a 
process  maturity  beyond  SEI  level  3,  in  a  COST  EFFECTIVE  manner 

•  STARS  has  developed  point  solutions  to  begin  addressing  this 
problem  -  there  is  much  work  yet  to  do 

fiMB^  M  iaUmtm  hwr.'AaA'Ca 
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ENACTING  THE  SOFTWARE  PROCESS 

S/W  MODULE  SPEC  PROCESS 


PAD  ASSIGN  SW_MODULE_SP£CIFICATTON  TASK 


PAD  PREPARE  SW_M0DULE_SPECIF1CAT10N 

PA3)  CONDl’CT  TEAM  REVIEW  OF  SW_MODULE_SPECIFICATION 

PA4)  REVIEW  TEAM_R£VIEW_RESULTS  AND  ACCEPT  OR  REJECT 
SW_MODULE  PECmCATION 

Notes  on  reading  the  following  process: 

1)  Arguments: 

a)  INCR  =  increment 

b)  SWENG  =  software  engineer  id  number 

c)  WKI  =  work  item,  such  as  a  SW_MODULE_SPECrFICATION 

d)  RTNO  =  count  of  individuals  on  The  review  team 


Enjcanf  the  Softwaic  Prooeu/Exi//VC23« 


ENACTING  THE  SOFTWARE  PROCESS 

ASSIGN  SW  MODULE  SPECIHCATION  I  ASK 


AGENT:  S0FTWARE_INCREMENT^MANAGER; 

SUBTASKS: 

1)  DO  PLAN_SOFTW ARE  INCREMENT  UNTIL  COM!  LETED; 

2)  INCREMENT.  PLANTflEDJTATEONCR)  :=  ’TES”; 

veil:  IF  ‘lNCREMENT_PLANNED_STATE(INCR)  =  ”YES” 

THEN  DO  PAT12; 


PAT12:  ASSIGN  SOFTWARE  MODULEJPECin  NATION  TASK  TO  AN  AVAILABLE 
SOFTWARE  ENGINEER  "  _ 


AGENT:  S0FTWARE_INCREMENT_MANAGER; 

SUBTASKS: 

1)  DO  n)ENTIFY_AVAlLABLE^SOFTWARE_ENGINEER  UNTIL  COMPLETED; 

2)  DO  ASSIGN_S0FTWARE_ENGINEER_T0_TASK  until  COMPLETED; 

3)  SW_ENG_INCREMENT_RESOURCE_STATE(lNCILSWENG,WKD  :=  ”ASSIGNED_WKr’ 
VC12:  ~  IF”sW_ENG_INCREMENT_RESOURCE_STATEaNCR^WENG,WKD  = 

”ASaGNEr>_WKr’ 

THEN  DO  PAT13; 

/•  software  ENGINEER  CAN  ACCEPT  WORKLOAD  AM)  HAS  BEEN  ASSIGNED  A 
software  module  SPECmCATlON  TO  WORK  ON  •/ 


Eautnt  the  Softwire  PtoceM/En//VG24 
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ASSIGN  SW  MODULE  SPECIHCATION  TASK  (CONT) 


PATU:  SCHEDULE  WORK  ASSIGNMErJT  REVIEW 


AGENT:  SOFTWARE_IN’aiE\IENT_MANAGER; 

SUBTASKS: 

1)  DO  SCHEDULE_WORK_ASSIGNMENT_R£VIEW  UNTIL  COMPLETED; 

2)  REVIEW_WORK_ASSIG^\MENT_STATE(INCR,WKI)  :=  "SCHEDULED” 

VC13:  EF~  REVIEW_WORK_ASSiGN'MENT_STATE(INCR,WKI)  =  "SCHEDULED” 

THEN  DO  PAT14; 


PATU:  REVIEW  WORK  ASSIGNMENT  WITH  SW-ENGINEER 


AGENT:  SOFTWARE_INCREMENT_MANAGER,  SOFTWARE_ENGINEER; 
SU'BTASKS: 

1)  DO  REVIEW_WORK,ASSIGNMENT_WITH_SW_ENGINEER  UNTIL  COMPLETED; 

2)  REVIEW_^w6rK_ASS1GNMENT_STATE  :s  "COMPLETED”; 

VC14:  rF”  REVIEW_WORK_ASSIGN'MENT_STATE(INCR,WTa)  =  "COMPLETED” 

THEN  DO  PAT15; 


PAT15;  RECORD  WORK  ASSIGNMENT  IN  PROJECT  MANAGEMENT  TOOL 


AGENT:  S0FTWARE_INCREMENT_MANAGER; 

SLTBTASKS; 

1)  DO  RECORD_WORK_ASSIGNME>nr  UNTIL  COMPLETED;  . 

2)  RECORD  WORK  ASSIGN'MENT(INCR,WK3)  "TRUE"; 

VC15:  EF’rECO^  W0RK_ASSIGNMENT(1NCR,WKD  =  "TRUE" 

THEN  SOFTWARE_MODULE_SPEC_STATE(INCR,WKD  :=”WIP" 
AND  PASS_PA1(INCR,WKD  :=” "TRUE"; 

/•  VERDT’sOFTWARE  manager  has  RECORDED  THE  WORK  •/ 


PASS_PA1(INCR,WKD  =  ”TRLE’ 
THEN  DO  PA2; 


ENACTING  THE  SOFTWARE  PROCESS 

PA2:  PREPARE  SAV  MODLXE  SPECinCATIOX  TASK 


ENTRY  CRITERIA  FOR  PA2; 


IF  PASS_PA1(INCR,WKI)  =  ’TRUE” 
THEN  PASSJPAI  :=  "DO.VE”, 

DO  PAT21; 


TASKS  FOR  PA2: 


PAT21:  DEVELOP  SOFTWARE  MODULE  SPECinCATION  (USING  BLACK  BOX 
TECHMQLXS 


AGENT:  SOFTWARE  ENGINEER; 

SL'BTASKS: 

1)  DO  BLACK  BOX  STEPS; 

2'  DO  SOFTWARE  MODLTJE  SPEC  SELF  VALIDATION  UNTIL  COMPLETED; 

3)  SOFTWARE.MODULE  SPic  STATE(INCR»WKI)  ;=  ”SELF_VALroATED”; 

4)  DO  PREPARi.SW_MODULE3PEC_METRIC.FORM(INCRrWKD  UNTIL  COMPLETED; 

5)  SW_M0DULE“sPEC.METRIC_F0£M^STATEaNCR,WKD  :=  "COMPLETED”; 

VC21: 

IF  SOFTWARE_MODLXE  SFEC.STATE(INCR,WKD  =  ’’SELF_VAUDATED” 

AND  SW  MODULE  SPEC  NffiTRIC  FORM_STATEaNCR,WKI)  =  "COMPLETED” 
THENDOPAT22; 

/•  SOFTWARE  ENGINEER  VALIDATES  THAT  ALL  STIMULI  AND  RESPONSES  IDENTmED  HAVE 
BEEN  ACCOUNTED  FOR  •/ 


PAT22:  REQUEST  TEAM  REVIEW  OF  SOFTWARE_MODL’LE_SPECIF1CATION 


AGENT;  S0FTWARE_ENGESEER; 

SUBTASKS: 

1)  DO  REQUEST_TEAM_REV1EW_0F_SW_M0DLXE_SPEC  until  COMPLETED; 

2)  SW_MODULE~TEAM2REVIEw”sTATE^CR,WKi)  :=  "REQUESTED”; 

VC22:  If  SW_M0DLXE_TEAM_REVIEW_STATE(INCR,W'KI)  =  "REQUESTED” 

THEN  DO  PAT23;* 

Emcag  the  Softwve  Prooeu/Ea/A^G26 
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ENACTING  THE  SOFTWARE  PROCESS 

PA2:  PREPARE  SAV  MODLXE  SPECIHCATION  TASK 

(CONTINUED) 


PAT23:  SCHEDULE  TEAM  REVIEW 


AGENT:  SOFTWARE_LNCREMENT_MANAGER; 

SUBTASKS: 

1)  DO  TEAM_CALENDAR_COORDINATION; 

2)  DO  SCHEDULE_SW_MODULE_SPECmCATlON  UNTIL  COMPLETED; 

3)  SOFTWARE_M6DL'LE_TEAM~REVrEW_STATE(INCR,WKD  :=  "SCHEDULED”; 

VC23: 

IF  SOFrWARE_MODLXE_TEAM_REVIEW_STATE(INCR,WKD  =  "SCHEDULED” 
THENDOPAT24; 

/•  software  ENGINEERING  MANAGER  SCHEDULES  TEANI  REVIEW  •/ 


PAT24:  FREEZE  SOFTWARE_MODULE_SP£CinCATION 

4GENT:  SOFTWARE  INCREMENT_MANAGER; 

SUBTASKS; 

1)  DO  PREPARE_C0NTIGURATI0N_MANAGEMENT_ENTRY(INCR,WKD  UNTIL  COMPLETED; 

2)  SOFTWaRE_MODUXE_SPEC_STATE(INCR,WKD  ;=  ”IN_REVIEW”; 

VC24: 

ff  S0FTWARE_M0DUXE_SPEC_STATE(INCR,WKD  =  TN^REVIEW” 

THEN  PASS_P2(INaLWKD  ::*~”TRUE”; 

EXIT  CRITERIA:  PA2 


IF  PASS_PA2(INCR,WKD  =  "TRUE” 
THEN  DO  P^; 


Eoacont  dM  SoAwait  Ploocu/Eo/A'C?' 
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ENACTING  THE  SOFTWARE  PROCESS 

PA3:  CONDUCT  TEAM  REVIEW  OF  THE 
SOFTWARE_MODLXE_SPECIFICATION 


ENTRY  CRITERIA  FOR  PA3: _ 

IF  S0FTVVARE_M0DULE_TEAM_REVIEW_STATE(INCR,WKD  =  ”SCHEDULED” 
AND  START_START_REVIEW_DATEaNCR,wa)  =  CURR£NT_DATE 
THEN  PASS_PA2  :=  "DONE”, 

DO  PAT31; 


IASK5.FQRPA3; 


PAT31:  PRESENT  SOFTWARE  MODLXE  SPECfflCATION  AND 
COMPLIANCE  TO  VALIDATION  CRITERIA 


AGENT:  software  ENGINEER  TEAM_MEMBERS(RTN0),  TEAM_M0DERAT0R; 
SUBTASKS: 

1)  DO  TEAM  REVIEW  PRESENTATION  UNTIL  COMPLETED; 

2)  TEAM  REVIEW_PR£SENTATION_STATUS(INCRWTa):s  "FINISHED”; 

3)  DO  CO'mPLETE  jrEAM_REVIEW_METRIC_FORM  UNTIL  COMPLETED; 

4)  TEAM^REVIEW*  PRESESTATION^STATU^CRWKI)  :»  "FINISHED”; 

/•  REVIEW  1)  TEAM'mODERATOR  RECORDS,  2)  ALL  SPECDICATION  PROBLEMS  AND 
TYPES  ENCOUNTERED  DURING  THE  REVIEW  AND  3)  TIMES  TAKEN  FOR  THE  REVIEW 
•/ 

5)  DO  HOLD_ACCEPT_OR_REJECT_DlSCUSSIONS  UNTIL  COMPLETED; 

6)  TEAM_REVIEW_SW_m6dULE_SPEC_ACCEPT ANCEONCRWKI)  :=  ”PASS”  |  "FAIL”, 

7)  SW_MdDULE_TEAM_REVIEw”STATEaNCRWKI) :»  "COMPLETED”; 

S)  DO  COMPLEfE_TEAM_REVIEW_MODERATOR_SCRIPT  UNTIL  COMPLETED; 

9)  TEAM_REVIEW”  MODaUTOR_SCRIPT_STATUS  :=  "COMPLETED”; 

VC31: 

IF  TEAM_REVIEW_PRESENTATION_STATUS<'INCR,WKD  =  "FINISHED” 

AND  TEAM"REVIEw"MET?UC_FORM3TATUSaNCRWK3) «  "COMPLETED” 

AND  TEAM^REMEW_SW_MODtXE_SPEC_ACCEPTANCE(lNCRWKD  = 

"PASS”  1  "FAIL”,' 

AND  TEAM_RE\TEW_MODERATOR_SCRIPT_STATUS  =  "COMPLETED” 
THENDOPAT32; 


Eaaaai  ihc  Scftwm  pToom/Ea//VG2S 
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ENACTING  THE  SOFTWARE  PROCESS 

PA3:  CONDUCT  TEAM  REVIEW  OF  THE 
SOFTWARE_MODUXE_SPECIFICATION  (CONTINLTID) 


PAT32:  COMPLETE  CHECKLIST  FOR  SOFTWARE_MODULE 
SPECmCATION  REVIEW 


AGENT:  TEAM_MEMBERS  (INCLUDING  TEAM  MODERATOR  AND  PRESENTOR); 
SUBTASKS: 

1)  DO  COMPLETE_CHECKLIST  FOR  SW  MODULE  SPEC(INCR,WKLRTNO) 

UNTIL  COMPLETED; 

2)  TEAM_REV1EW_SW_M0DULE  SPEC  CHECKLISTaNCR,WKI3lTNO)  := 

"COMPLETn)” 

2)  DO  SEN'D_FORM  UNTIL  COMPLETED; 

3)  REVIEW  >ORM_SENT(INCR,WKLRTNO)  :=  *TTIUE”; 

VC32: 

IF  TEAM_REVIEW_SW_MODCLEJPEC  CHECKLIST(INCR,WKJ)=’X:0N1PLETED” 
AND  REVTEW_FORM jEyr(INCR,wkD  =  -^UE” 

THEN  PASS_PA3(INCR^Ta)  •^’THUE"; 

/•  TEAM  REVIEW  CHECKLIST  FOR  SOFTWARE  MODULE  SPECEFTCATIONS  HAVE 
BEEN  COMPLETED  AND  SENT  TO  THE  MEETING  REQUESTOR  •/ 

EXIT  CRITERIA!  PA3 


IF  PASS_PA3(INCR,WKI)  =  "TRLE” 
THEN  DO  PA4; 


EaiOMii  dM  Pnioeu/Ea//VC29 
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ENACTING  THE  SOFTWARE  PROCESS 

PA4:  REVIEW  TEAM_REVIEW_RESULTS  AND  ACCEPT 
OR  REJECT  SW^MODULE_SPECIFICATION 


ENTRY  CRITERIA  FOR  PA4: 


IF  PASS_PA3<INCR,WKD  =  ’TRUE” 
THEN  PASSlPA(lNCR,VMa)  :=  ’T)ON'E” 
DO  PA41; 

TASKS  FOR  PA4: 


PAT41:  REVIEW  SOFTWARE  MODULE  SPECIFICATION  TEAM  REVIEW 
RESULTS  AND  ACCEPT  OR  REJECT 


AGENT:  S0FTWARE_INCREMENT_MANAGER; 

SUBTASKS: 

1)  DO  REVIEW  (  TEAM.REVIEW_MODERATOR_SCRlPTaNCR,WTa), 

SW  MODULE  SPEcinCATION(INCR,WKD, 

(ClffiCKUST  FOR  SW  MODLUE  SPEC(INCR,WKLRTNO) 

FOR  RTNO  =  1  THRU  REVTEW_TEAM  COLTsT)  ) 
LTOTL  COMPLETED; 

2)  IF  TEAM,REVIEW^SW^MODULE_SPECinCATION  =  "PASS” 

AND  IS  FOUND  ACC^AJBLE  BY  THE  SOFTWARE  INCREMENT  MANAGER 
THEN  SW_M0DULE_SPECmCAT10N_STATE(lNCR,WTCD  ;=  "COMPLETED” 
ELSE  Sw"MODL’LE~SPECinCATION3sTATE(INCR,WTa)  :=  ”Wir’; 

VC41:  IF  SW_M0DULE_SPECinCAT10N_STATE  =  "COMPLETED” 

THEN  PASS_PA4(INC'R,^Ta)  :=  ’TRUE” 

ELSE  PASS JPA4(INCR,WKD  ;=  "FALSE”; 

EXIT  CRITERIA;  PA4 


IF  PASS_PA4(INCR,^Ta:)  =  "TRUE” 
THEN  FXIT" 

ELSE  DOPA2; 


Eaacons  ibc  Scftww  Preecu/Ea/'/VClO 
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procejS  measurement 

OUTLINE 

•  Motivation  for  Measurement 

•  Process  vs  Product  vs  Project  Management  Metrics 

•  Measurement  Systems 

•  Measurement  Capabilities  in  STARS  Products 

•  Near-Term  Payoff  Opportunity 

OUTLINE 


rm  going  to  present  to  you  the  ’ymY,”  the  "WHICH,"  the  "WHAT."  the  "WHERE,"  and  the 
"WffiN"  of  the  Measuieznent  facet  of  process-driven  developmcnL 


Proetts  MeasurmoMHcrtlVGl 


PROCESS  MEASUREMENT 

MOTIVATION 


You  can^t  control  and  improve 
what  you  can^t  measure 

•  Applies  to  quality  characteristics  of  software  Products 

•  Applies  to  software  development  Processes 
(including  Project  Management  activities) 


•  Also  applies  to  processes  outside  the  software  field,  e.g.,  Industrial 
control  processes,  Business  enterprise  processes,  Sports  training 
processes,  etc. 


MOrrVATION 
Measurement  — • 

How  can  we  tell  that  we  have  a  good  process?  —  We  have  to  measure  it! 

How  can  we  tell  what  to  change  if  our  process  isn't  good  enough?  —  We  have  to  be  able  to 
measure  iU 

How  can  we  tell  if  the  change  was  a  step  forwards  or  a  step  badcwards?  —  We  have  to  be  able  to 
measure  it 

How  can  we  tell  if  die  change  had  enough  benefit  to  offset  the  cost  of  instituting  the  change?  —  We 
have  to  be  able  to  measure  it! 

You  can’t  control  and  improve  what  you  can’t  measure! 

It  has  been  fairiy  well  accepted  that  measurements  and  metrics  are  useful,  if  not  crucial,  to  judging 
the  QUALITY  of  software  products  developed  by  teams. 

The  same  applies  to  software  development  processes,  and  those  aspects  of  development  processes 
that  interact  with  Projea  Management  activities,  which  are  subset  of  a  project's  total  activities. 

Of  course,  most  of  what  we're  talking  about  here  in  the  measurement  area,  and  most  of  all  our 
efforts  in  the  whole  Process  area,  apply  outside  the  software  development  domain  as  well  — 
industrial  control  processes,  business  enterprises,  etc. 
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PROCESS  MEASUREMENT 

PROCESS  DRIVEN  DE\^LOPMENT 


RELATIONSHIP  TO  OTHER  STARS  PROCESS  ACnVHIES 

Measurement  plays  a  very  central  role  in  the  vision  STARS  has  for  Process. 

'Monitor  and  Measure”  is  right  in  the  middle,  in  the  middle  of  a  large  loop,  of  our  Process*Dnven 
development  operational  concept  It  effects  just  what  I  said:  Being  able  to  evolve  and  improve  the 
Process  Definitions  and  improve  the  Processes  in  Action  in  the  future. 

There's  another  loop  shown  here  though,  where  measurement  can  acmally,  within  (during)  a 
project  be  us^  to  improve  the  activities  of  a  project  This  is  DECISION  MAKING,  Measurement- 
assisted  decision  making,  empirical  dau  measurements  assisting  human  decisions  du^g  a  project 
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GOAL 


A  STARS  GOAL  IS  INTEGRATION  OF 
MEASUREMENT  AND  PROCESS 


Guide  decision-making  during  a  development  process,  given 
impossibility  of  completely  specifying  a  process  that  covers  every 
situation 

-  Provide  empirical  data  and  analysis  to  assist  decision-making 

-  For  example,  resource  re-allocation  during  Integration  &  Test  as 
its  impact  becomes  apparent 


Provide  evidence  upon  which  to  evaluate  which  process  steps  are 
working  effectively  and  which  are  not,  leading  to  Process 
Improvement 


A  STARS  GOAL  IS  INTEGR.\TION  OF  MEASUREMENT  AND  PROCESS 

So,  I  repeat,  one  of  STARS's  two  major  goals  in  the  Process  Measurement  area  is  to  assist  or  gtude 
Decision  Making,  collecting  and  presenting  for  use  empirical  evidence  data  that  makes  project 
decision  making  on  finner  ground  than  it  was  without  quantitative  data. 

For  example,  being  able  to  re-allocau  resources  during  Integration  and  Test  G&T)  as  certain  modules 
are  found  to  not  integrate,  and  perhaps  causing  ripple  effects  if  there  are  a  select  few  modules  found 
to  be  troublesome  in  their  interfaces  with  many  other  modules,.  This  has  an  impact  on  the  process 
and  particularly  on  Project  Management  activities  in  their  allocation  of  manpower 

But  then,  it's  overall  Process  Improvement,  institutionally,  over  the  long  run,  spanning  all  of  an 
organizadon's  projects  over  the  years,  that  is  the  other  dimension  where  Measurement  is  cridcal,  and 
is  the  other  major  STARS  goal  in  the  Process  Measurement  area.  This  was  the  big  loop  I  showed 
first  on  the  previous  chart 
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PROCESS  MEASUREMENT 

MEASUREMENT  IN  THE  SEI’s  CMM 


More  Measurements 
are  now  required  at 
Levels  2  &  3:  Example 


Maiuritv  Lfveir 
Repeatable 


Key  Process  Area: 

Softvrare  Project  Ti-acking 
and  Oversight 


Kev  Practice 


Actual  results  and  performance  of 
software  projects  are  tracked  against 
docutr  tnted  and  approved  plans 


Ker  Practice 


JCw  lodicaur 


Corrective  actions  arc  taken  when  the 
aaual  results  and  pe^ormance  of  the 
software  project  deviate  significantly 
^  from  the  plans  / 

:s: 


Qc<y  IfldiQtor^ 


I 


Question: 


Do  you  use  an  tanud-raUu  planning  tyium,  a 
resource  traeiang  system,  and  icheduUd  proetdum 
to  analfu  ant  agains:  the  other? 


Question: 


How  do  you  impitmtnt  correedvt  actions:  s  . 

Can  you  show  examples  from  past  projects  of  |  I 
orders  for  conrecart  actions,  follow-ups ,  [/ 

dispostaons,  and  reports  on  effeedetness? 


Extensive  Process  measurement  and  analysis  is  still  at  Level  4, 
and  Optimization  based  on  it  is  at  Level  5.) 


rWM.lUi  imrmmwHmeVGi 


MEASUREMENT  IS  MORE  IMPORTANT  IN  THE  NEW  SO  CMM;  An  Example 

Here's  another  reason  why  I  think  everybody  in  the  room  ought  to  be  concerned  about  Measurement: 
Measurement  plays  a  prominent  role  in  the  SEl's  process  Capability  Maturity  Model  (CMM) .  In 
fact  in  the  1991  version  of  the  CMM,  Measurement  is  more  important  at  Level  2  than  it  was  before. 
Using  the  style  of  the  Key  Practices  assessment  model  there,  here’s  an  example  &om  Level  2; 

“Software  Project  Tracking  and  Oversight”  is  a  key  area  at  Level  2  now.  Two  key  practices 
establishing  that  Level-2  capability  are  (1)  tracking  actual  project  results  against  approved  plans,  and 
(2)  taking  corrective  actions  when  actual  projea  results  deviate  significantly  from  plans. 

Key  indicaton  of  these  key  praedees  are  the  following  two  questions  which  might  be  asked  of  an 
organizadon  undergoing  a  capability  assessment  or  a  contractor  evaluadon:  (1)  “Do  you  use  an 
eamcd-valuc  planning  and  repordng  system,  a  resource  tracking  system,  and  re^larly  scheduled 
procedures  to  compare  one  to  the  other?”  and  (2)  "How  do  you  implement  correedve  actions?  Can 
you  produce  documented  examples  from  past  projects  of  orders  for  corrective  actions,  an  follow-up 
reports,  reponr  of  dispositions,  and  reports  assessing  effectiveness  of  such  corrective  actions?” 

Overall,  there  are  more  measurements  are  now  called  out  in  the  Key  Practices  at  Levels  2  and  3 
than  there  were  before. 

Extensive  incorporation  of  process  measurement  and  analysis  for  identifying  improvement 
opportunities  is  still  the  essence  of  Level  4,  and  incorporating  Process  Improvements  based  on  that  is 
still  the  essence  of  Level  S. 
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PROCESS  MEASUREMENT 

PROCESS  OBJECTIVES  &  METRICS 


EXAMPLE  PROJECT  PROCESS  OBJECTIVES  &  ASSOCIATED 
METRICS: 

•  Prioritize  ECPs:  complexity  &  error-history  measures 

•  Make  vs  Buy  decisions:  Effort  &  Quality  (or  defect  rate)  histories 

•  Design  For  Reuse:  Correlations  of  design  approaches  to  domain 
characteristics  sensitivity 

•  Design  for  maintainability:  Correlations  of  design  approaches  to 
ease  of  change 


PROCESS  OBJECTIVES  and  METRICS 

I  will  introduce  and  distinguish  3  different  kinds  of  metrics  on  the  next  chart:  Product,  Process,  and 
Ihcject  Management  metrics. 

Some  quick  examples  of  Process  objectives  and  the  associated  metrics: 

Prioritizing  Engineering  Change  Proposals  —  how  do  you  tell  which  ones  are  the  most  important  to 
work  first,  or  which  ones  require  the  most  staffing?:  Complexity  and  error-history  measures,  enor- 
proneness  and  past  histories  of  trouble  with  particular  modules  are  very  useful  measures. 

Make  vs  Buy  decisions:  Does  the  Effort  offset  the  gain  in  Quality  relative  to  buy  ...  Effort  and 
Quality  (or  defect  rate)  histories  give  helpful  indications  of  how  to  make  this  decision. 

Designing  For  Reuse:  Reuse  is  an  increasingly  important  project  objective;  do  you  have  some  data 
that  indicates  for  your  applicarion  domain,  one  design  approach  will  increase  the  reusability  index 
relative  to  others?  Correlations  of  design  approaches  to  domain  characteristics  sensitivity  are  results 
of  measurements. 

Same  for  Maintainability,  and  the  answer  may  or  may  not  always  be  tlie  same  as  the  answer  fur 
Reuse.  Correlations  of  design  approaches  to  ease  of  cnange  are  key  to  examine  here,  and  a  history 
of  measurements  of  change  activity  against  various  design  approaches  in  the  subjea  domain  would 
help. 

These  questions  can  be  answered  if  you  have  an  empirical,  quantitative  history  database. 
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PROCESS  measurement 

3  USAGES  OF  METRICS 


PROCESS  vs  PRODUCT  vs  PROJECT  MANAGEMENT  METRICS 


•  Product  measurements  can  be  inputs  to  Process  measurements 
and  Project  Management  activities 

-  The  difference  is  only  Ho'w  they're  used 

-  Project  Mgmt  Measurements  could  improve  Process  too 

EXAMPLES 


QUALITY  PRODUCTIVITY  PREDICTABILITY 

(Coafortnance  to  (Outputs  produced  (Improve  estimatint, 

Customer  requirements)  /  Inputs  consumed)  plaoning,  &  tracking 


Product  Metrics 

Sue,  Complexity 
#  Defects  in  a  Module 
Reusability 
Reliability 
Testability 


Process  Metrics 
Effort  &  Cost 
Defects  found 
Defects  corrected 
Defect  source  identincation 
Milestone  completion 


Project  Mgmt  Metrics 
Size 

Cost  SlIot  Effort 
Actuals  vs  Budgets 
Earned  Value  vs  Budgets 
When  is  activity  done'! 


fnM.Uniir»  vHmtVg 


PROCESS  vs  PRODUCT  vs  PROJECT  MANAGEMENT  METRICS 

Now,  looking  at  all  3  kinds  of  metrics  together  (Pnxiuct,  Project  Management,  and  Process  metrics), 
Produa  measurements  at  the  lowest  level  are  what  is  usually  coUected  in  practice  today,  sometimes 
manually,  sometimes  by  tools.  How  you  establish  relationships  or  analyze  particular  product  metrics 
may  make  them  also  inputs  to  Process  Measurements,  or  they  may  make  them  into  Project 
Management  measurements.  As  I  asserted  before.  Project  Management  activities  are  just  a  subset  of 
total  project  process,  so  project  measurement  may  be  rightly  regarded  as  a  subset  of  process 
measurements. 


The  chart  lists  some  examples  of  each  of  the  three  lands  of  metrics  No  surprises  here  for  Product 
metrics.  Some  of  them  may  be  hard  to  measure  other  than  based  on  comparisons  with  empirical 
feedback  from  previously  d^loyed  modules.  Most  Produa  Metrics  relate  to  QUALITY  objectives. 
Software  module  Complexity  has  long  been  regarded  as  a  key  indicator  or  immediate  and  future 
problems;  many  of  you  are  familiar  with  S(3me  of  the  varying  Complexity  metrics  sets,  such  as 
(McCabe’s)  Cyclomatic  Complexity  numbers,  (Halstead’s)  Software  Sciences  metrics,  function 
points,  path  aniysis,  fan-in/fan-out  counting,  etc.  Now,  with  Process  metrics,  PRODUCTTVITY  is 
the  encompassing  goal.  Qearly,  Productivity  includes  (Quality  as  a  dimension,  for  example.  Quality 
measurements  dbectly  affect  the  numerator  in  a  quotient  of  Product  Value  (divided  by  effon  and 
other  resources  consumed)  which  calculates  Productivity.  In  other  words,  QUALITY  is  an  essential 
factor  in  Process  measurement!  Project  management  metrics  and  activities,  generally  deal  with 
PREDICTABILITY  —  estimating,  planning,  and  tracking  of  progress  against  that  plan,  which  may 
be  same  as  the  F^ess  Plan. 


You  see  that  some  of  these  mecrics,for  example,  size,  appear  in  more  than  one  of  these  columns. 
What  this  really  illustrates  is  that  most  of  the  Product  metrics  are  among  the  basic  inputs  combined  to 
establish  whether  estimates  are  good  or  bad  and  to  improve  estimating,  to  develop  plans  and  to  assist 
replanning.  For  example,  under  Project  Management.  Tracking  is  a  relationship  between  various  of 
these  Product  metrics  and  schedule  or  calendar. 
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PROCESS  MEASUREMENT 

METRICS  m  PROCESS  MGMT  PARADIGM 


METRICS  IN  THE  PROCESS  MANAGEMENT  PARADIGM 


This  diagrani  you  saw  in  Tun  King's  presentation  and  it  puts  the  roles  of  these  3  kinds  of  pnxess 
metrip,  their  similarities  and  differences,  in  the  total  context  of  the  Process  Management  para^gra  of 
definition  through  instantiation  on  particular  projects  through  the  carrying  out  of  the  process  for  a 
particular  projea  in  a  software  engineering  environment  —  the  measurement  role  and  the  feedback 
to  be  able  to  improve  the  definitions,  either  of  the  projects  or  institutionally.  Added  on  here  are,  so 
you  can  sec  the  relationships  between  them  arc  process  metrics,  project  metrics,  and  project 
management  metrics,  which  may  be  collected  by  monitoring  tools  separately  from  the  Software 
EngineeTing  tools,  or  they  may  arise  from  part  of  the  information  collect^  by  Software  Engineering 
tools.  Some  of  those  arc  analyzed  in  ways  that  make  their  usage  projea  management  information, 
and  some  of  them  are  pr^uct  metrics  used  by  the  project  team  to  gauge  their  convergence  on 
customer  satisfaction  (quality)  goals. 

The  metrics  are  used  for  different  purposes,  but  there’s  a  lot  of  similarity  between  them.  And, 
there's  a  lot  of  similarly  between  where  they’re  detected  and  stored  in  the  SEE.  As  I  said  before, 
produa  metrics  in  most  cases  are  also  inputs  for  calculating  Project  Management  and  Process 
metrics. 
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GOING  BEYOND  PRODUCT  METRICS 


PROCESS  MEASUREMENT  GOES 
BEYOND  PRODUCT  METRICS 

•  Feedback  analysis  to  Improve  Decision-Making  during  software 
development  processes 

•  Correlation  and  validation  of  Estimating  techniques 

•  Correlation  of  selected  process  steps  to  product  Quality 

•  Feedback  analysis  to  Improve  Processes 


GOING  BEYOND  PRODUCT  METRICS 

So.  let's  recap:  How  does  Process  Measurement  go  beyond  the  in*pr«ctice  notion  of  Product 
metrics? 

It's  the  PROACTIVE  usage  of  mewurement  that  distinguishes  Process  meuics  activities  from 
Ptnduct  metrics.  Collecting  the  metrics  might  be  clearly  a  product  measurement,  but  project  acttons 
that  are  irftuenced  or  changed  due  to  analysis  of  metrics  are  Process  actions. 

For  example,  feedback  analysis  to  Improve  Decision-Making  during  software  development 
processes. 

Or,  refinement  of  Estimating  techniques  by  comparing  past  estimating  procedure  outputs  to 
subsequent  actuals,  thereby  either  validating  the  estimating  procedure  or  suggesting  improvements 
based  on  the  empirical  data. 

Or,  determination  of  which  process  steps  correlate  most  directly  to  produa  Quality,  in  the  sense  that 
increasing  effort  in  particular  process  steps  leads  most  directly  to  Quality  gains,  thereby  improving 
an  organiation’s  process(cs)  tor  fumre  projects. 


This  is  essence  of  why  we  deal  with  Process  Measurement  If  you  don't  have  the  vision  of 
improving  and  institutionalizing  processes,  you  may  collect  many  product  metrics  and  not 
accomphsh  any  improvement  You  might  not  even  be  getting  basic  assistance  in  achieving  your 
current  products  customer-satisfaction  objectives. 
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PROCESS  MEASUREMENT 

MEASUREMENT  SYSTEMS 


•  Provide  a  way  to  speciiy  User-defined  metrics  to  collect 
+  usually  a  tailorable  default  set  of  metrics 

•  Instrumentation 
'  Collection 

•  Reporting 

-  Including  feedback  for  decision  making  or  improvement 

•  Proactiveness 

-  Automatically  trigger  specified  process  steps  when  certain 
metrics  values  or  thresholds  are  attained 

-  For  example,  project  replanning  when  %  calendar  schedule  is 
inconsistent  with  product  Earned  Value 


MEASUREMENT  SYSTEMS  are  how  one  collects  these  metrics.  Maxiy  of  the  metrics  are  spcdfic  to  a  project  or  an 
cr^izaiion,  and  hence  are  user  defined,  in  the  sense  of  the  project  member  or  another  organization  representative  such 
as  SEPG  members.  Usually  there's  a  core  set  of  default  metrics  that  everyone's  interested  in,  so  tliey're  aU  jaovided  by 
a  Measuranem  Systeos  as  automatic  user  selections,  for  example,  (Source)  Lines  of  Code  (SLOC  or  LCXT)  predicted 
and  produced  [no  one's  favorite  metric,  but  too  widely  used  to  ignore]  ...And  so,  measuring,  storing,  and  counting 
SLOO  associated  with  modules  and  subsystems  a  one  of  those  metrics  you  expect  to  be  collect^  in  anybody's 
minimalisdc  Measorement  System.  These  systems  provide  fcv  instrumentation,  that  is  the  identiHcatioa  of 
circumstances  or  points  in  a  process  at  which  different  metrics  are  established  and  available.  They  provide  collectian  of 
measurements  based  on  what's  been  instrumented  into  activities.  They  provide  reporting,  which  can  be  done  in  a 
variety  of  ways,  including  numerical  calculations  and  analyses  for  feedbag  or  presentation,  perhaps  interactively,  to 
projea  managen  or  perhaps  other  team  members  in  making  tbe  decisions  that  inevitably  come  up  because  we  don't 
have  perfect  insight  into  defining  every  minute  detail  of  processes  ahead.  So.  there's  always  a  degree  of  uncertainty 
about  software  processes  (as  with  almost  all  human  endeavors)  going  into  the  project 

Proactiveness  —  that's  one  of  our  goals.  To  be  able  to  really  support  the  well  disciplined  recognition  of  when 
particular  metrics  cross  thresholds  or  attain  specific  relationships  that  should  trigger  specific  events,  process  steps,  for 
example,  when  l&T  has  expended  50%  of  its  budget  and  only  20%  of  the  modules  have  come  together  (or  maybe  even 
50/50  is  a  red  flag,  since  you  might  expect  (he  easier  ones  to  be  done  first)  somebody  ought  to  take  corrective  actions, 
perhaps  replanning,  perhaps  changing  test  cases,  perhaps  changing  integration  method.  Or,  when  a  certain  %  of  the 
total  project  calendar  has  passed  and  the  measured  system  product’s  Earned  Value  that  is  collected  in  the  EV  system  is 
Car  less  than  that  %  (assuming  the  plan  calls  for.  and  has  £V  measurements  supporting.  EV  growing  according  to 
resource  or  schedule  expenditure). 

Notice  I  didn't  say  anything  on  this  chart  about  Automation.  All  of  this  can  be  done,  and  much  of  it  is  being  done  in 
pncsice  today,  manu^y  in  many  organizations.  It's  an  obvious  opportuiuty  for  automation,  although  not  absolutely 
mandatory.  STARS's  objective  is  to  provide  low-cost  measurement  capabilities,  based  on  automated  aids,  that  clearly 
outweigh  their  costs  in  providing  thorough,  timely,  reliable,  flexible  measurement  information  for  usage  by  all  of 
project  technical  personnel,  projea  managers,  process  cneuieers,  and  organizauons  such  as  SEPG's.  Not  just  Process 
Metrics,  but  also  Product  and  Project  Management  meuics,  remembenng  that  the  collected  measurements  input  for 
these  3  purposes  are  often  the  same.  But.  Process  purposes,  which  in  a  sense  subsumes  the  purposes  for  the  other 
kinds  of  measurements  also,  is  our  main  modvition  in  STARS  developments. 
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PROCESS  measurement 

STARS  PRODUCT: 
ARCADIA’S  AMADEUS  SYSTEM 


An  Example  of  the  Science->Technology->Practice 
Pipeline  Working  at  DARPA  (Arcadia  ->  STARS) 

•  Developed  by  Univ.  of  Calif,  at  Irvine,  Prof.  Rick  Selby,  PI; 
part  of  Arcadia;  collaborating  with  industry  and  now  STARS 

•  Flexible  design-for-integration 

-  Stand-alone  'capability  now 

-  Integrated  v  .*h  Arcadia's  APPL/A  now 

-  Will  integral  with  other  SEEs  and  Frameworks 

•  Industry  Orient ition 

-  Proven  Meaiurement  &  Analysis  Algorithms 

-  Scalable 

•  Low  Entry  Barrier 


A  STARS  PRODUCT:  ARCADIA'S  A.MADEUS  SYSTEM 

One  measurement  system  that  STARS  is  cooperating  with  now  is  Amadeus ... 

This  is  a  good  example  of  the  Science->Technology->Practice  I^peline,  which  is  DARPA’s  long¬ 
term  misdon,  working  between  two  DARPA  programs:  Arcadia,  which  is  very  much  and  R&D 
program,  and  STARS. 

Amadeus  is  developed  by  Univ.  of  Calif,  at  Irvine,  with  Prof.  Rick  Selby  as  the  Principal 
Invesdgaior. 

Prof.  Selby  has  been  working  on  Amadeu.s  as  pan  of  the  Arcadia  consortiuni  for  about  4  years,  and 
also  in  collaboradon  with  local  industries  to  provide  history  databases  and  collected  metrics,  to 
validate  his  ideas  and  approaches  about  how  a  measurement  system  should  be  constructed  and 
by  inter,  .rting  with  people  responsible  in  companies  for  defining  and  carrying  out  measurement  and 
improvement  activides,  and  to  acquire  additional  algorithms  for  computing  various  measures.  So, 
Amadeus  has  already  advanced  beyond  the  level  of  university  prototype.  And,  collaboradon  with 
STARS  is  now  also  underway. 

Following  charts  will  overview  some  of  the  reasons  why  STARS  has  selected  Amadeus  as  a 
candidare  for  inserdon  into  STARS  S.'^iE's,  work  staned  now  and  andcipated  to  be  completed  in  the 
1993  timeframe.  These  important  features  of  Amadeus  include  flexible  design-for-integtadon, 
proven  incorporadon  of  measurements  and  decision  aids  useful  in  industry,  and  a  low<ost  of 
starting  to  use  it  in  current  tool  platforms  (such  as  Unix). 
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PROCESS  MEASUREMENT 

USERS  CONTROL  METRICS 


Amadeus  provides  flexibility  in  specifying  and  dynamically  changing 
what  causes  metrics  to  be  collected,  which  ones  are  collected,  and  what 
happens  with  them 

•  Provides  measurement  associated  with  the  3  common  kinds  of 

vents”  of  interest: 

-  Product  (data)  changes 

-  Process  events 

-  Time  (clock/calendar)  events 

•  User  specifies  interpretation  of  or  response  to  Events,  via 
“Agents”  which  may  trigger  any  other  program  or  process  step 

-  Association  of  particular  Events  with  specific  Agents  is  a 
measurement  system  parameter  easily  specified  and  changed  at 
any  time  during  a  project's  lifecycle,  via  “Scripts” 


THE  USERS  CONTROL  WHICH  METRICS 

The  Amadeus  system  Jias  the  ability  for  users  to  specify  events  of  3  different  kinds  of  Events:... 
(1)  Changes  in  project  products  or  data  (documents,  software,  test  daubase);  (2)  Process  events 
(for  example,  compledon  of  milestones  such  as  PDR  or  I&T,  or  usage  of  a  design  tool);  and  (3) 
clock-bas^  events  (passage  of  specified  intervals  of  calendar  time). 

Li  Amadeus  system,  there  is  the  capability  to  specify  Events  of  interest  at  the  time  projects  are 
started,  or  when  tools  are  installed,  or  even  by  resetting  notification  mechanisms  on  databases, 
frameivorks,  ra.tilers,  etc..  Such  Events  trigger  the  collecdon  of  pardcular  metrics  into  a  persistent 
database.  This  specificadon  is  detached  ^m  the  specificadon  of  Agents,  which  invoke  analysis 
procedures,  or  interact  with  project  members  in  a  decision-making  dialog.  Because  of  that 
decoupling  of  Agents  from  Events,  Amadeus  offers  a  great  deal  of  flexibility  to  modify  a  projea's 
measuremera  acdvides,  and  thereby  improve  the  process,  during  a  project. 
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CONCEPTUAL  OPERATION  OF  AMADEUS 


This  a  quick  conceptual  operation  illustration  for  Amadeus. 

The  scripts  represent  Events  that  are  of  interest  and  the  associated  Agents.  Each  script  specifies  one 
Event-Agent  pair.  These  are  what  are  set  up  at  project  initiation  and  that  can  be  changed  during  the 
carrying  out  of  the  project  An  Agent  may  trigger  Data  Collection  acdviries,  or  they  may  trigger 
analysis  programs.  The  Events  may  come  from  Process  Programs;  they  may  come  from  clocks;  or 
they  may  come  from  changes  to  the  data  store.  The  Amadeus  system  is  tied  to  an  environment’s 
persistent  storage,  and  provides  an  interpretive  approach  for  instiling  and  running  scripts,  thereby 
providing  the  ability  to  dynamically  change  what's  measured  during  a  project,  due  to  the  interpretive, 
not  hard-wired,  carrying  out  of  specified  measurement  activities.  Amadeus  provides  the  ability  to 
install  Analysis  Tools  that  may  be  become  available  after  projea  start-up,  perhaps  in  response  to 
Events  that  are  determined  after  project  stan-up  to  be  worthy  of  signalling  for  data  collection  or  other 
measurement  or  analysis  actions.  There's  an  event  stream  that  flows  through  this  interpreter,  and  if 
there's  no  script  currently  installed  and  activated  that  cares  about  a  panicular  event,  it  just  ’goes  on 
by."  But  if  you  later  decide  that,  for  example,  designs  weren’t  passing  reviews  even  after  rework, 
project  marjgcment  may  want  to  install  a  new  script  to  compute  and  collect  Complexity  metrics  over 
designs  after  every  update  to  the  design  database.  So.  a  user  can  either  author  a  script,  or  take  a 
script  from  a  translation  of  a  changed  Process  Program  that  descnbes  this  refinement  to  the  process, 
and  install  it  into  the  active  script  table,  and  that  panicular  process  improvement  would  henceforth  be 
effected  on  the  project  automatically. 
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AMADET'S  -  DESIGNED  FOR  INDUSTRY  USEFULNESS 


•  Scalability  addressed 

-  Multiple-server  architecture,  etc. 


•  Rich  set  of  error-detection  algorithms  validated  and  embedded 
-  Classification  Tree  tools  for  error-proneness  predictions,  etc. 


•  Assisting  decision-making  is  an  important  design  objective 
-  Many  empirically-based  decision  aids  are  implemented 


•  Joint  industry  efforts  to  test,  validate,  acquire  algorithms 


INDUSTRY  USEFULNESS 

Prof.  Selby  has  done  several  things  to  distinguish  Amadeus  from  blue-sky  prototypes. 

One  of  them  is  scalabifiiy.  He  las  observed  tod  learned  that,  witlwot  special  engineering  of  the  software  prototypes, 
loo  often  prototypes  that  worit  well  for  one-person  situatioos  fail  to  work  for  bondred-  or  thousand-person  siniatiras 
without  serious,  costly,  sometima  unachievable  redesign. 

His  approach  to  scalability  is  to  have  concurrem  interpreters,  multiple  instances  of  that  measurement  script  interpreter  I 
mennoned  on  the  previous  chan,  so  that,  depending  on  die  underlying  equipmem  architecture,  that  functionality  can  be 
distribmed  »  avoid  bottlenecks  with  tnooiioring  of  a  highly  concurrem  set  of  activities  oorresixmding  to  a  large  projea 
team.  Addiriocally.  they  architected  their  persistent  storage  as  general  utterfaces  that  are  known  to  be  typically 
anplemeatable  on  existing  commercial  dattbase  systems,  so  that  tbe  petfonnance  is  at  least  predictable  and  gradable 
with  respeo  to  very  large  volumes  of  data. 

I  mentioned  before  the  decoupling  ghreo  by  Amadeus's  design  between  the  events  that  signal  'nocnents  when  (be  state 
of  projea  development  is  worth  examining,  and  the  Agents  that  coUeo  specific  data  at  those  moments  or  perform 
actions  specified  in  responm  to  arriving  at  such  momena.  Recall  that  an  Agent  can  call  a  particular  analysis 
algccithm,  and  also  recall  that  the  Agents  can  be  remapped  to  Events  (meaning  analysis  changes)  by  changing  scripts 
during  a  project,  as  well  as  between  projeos  across  an  organizatioa  Amadeus  provides  a  fairly  extensive  set  of  useful 
analysis  algorithms,  from  both  the  research  community  and  industry  that  they  have  collected  (some  of  which  Prof. 
Selby  and  bis  colleagues  developed).  An  example  follows  on  the  next  chan  —  Classification  Tree  tools  for 
predkaing  error-proneness  modules. 

Assisting  decision  making  is  an  imponant  objective  in  Amadeus.  The  Amadeus  system  is  available  with 
implemeotatioos  of  basic  decision  aids  (like  those  I've  mentioned  earlier)  based  on  the  includ^  metrics  and  algotiduns. 
Of  course,  the  script  mechanism  allows  project  users  to  develop  theti  own  decision  aids  and  instali  them  into  their 
eoviicDmeni  flexibly  using  Amadeus. 
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Calibratable  to  new  environments 
Measurements  are  integratable 
Leverage  previous  experience 
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Focus  on  High-Payoff 
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Attribute-i 
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Attribute-] 


Attribute-k 
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;  Classified  as  EkeJy  to  have  property  P  (eg  integration 

errors) 


Attribute-! 


Real-tune  ^ 


Attribute-m 


Non-real 

^Ime 


*•*:  Classified  as  unlikely  to  have  property  P 
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EMPIRICALLY  BASED  TECHNIQUES:  A  CLASSIHCATION  TREE  EXAMPLE 

Auribuie  J  is  a  product  metric  gathered  or  computed  on  a  software  module  under  deveiopmem.  It  doesn't  necessarily 
have  to  be  quantified  (munerical);  it  could  be  ’Yes*  versus  *No,*  it  could  be  ’developed  by  computer  programmer’  vs 
•by  system  architect*  vs  "by  process  engineer*  vs  *by  lAT  team*;  it  could  be  a  refiecnon  of  a  reused  modules  heritage. 
Based  on  ranges  of  values  of  that  attribute  J.  other  product  metrics  of  interest  may  then  be  indicated  as  worth 
examining;  at  the  2nd  level,  the  algorithm  might  just  compute  one  metric  broken  into  many  ranges,  or  maybe  some 
diireient  metrics  with  fewer  ranges  each,  as  illustrated  in  this  e\>”*plc  which  depicts  a  classification  tree  to  identify 
moduka  likely  to  exhibit  some  troublesome  property.  Ibis  repeated  classification  might  be  repeated  hierarchically  at 
several  levels  in  the  case  illustrated  at  ie^,  3  at  right),  eventually  boiling  down  to  a  definitive  prediction  as  to 
whether  or  not  a  module  is  likely  or  unlikely  to  be  among  the  20%  most  error  prone,  or  to  exhibit  some  other  property 
which  is  the  abject  of  a  difTetcnt  classification  tree. 

A  surprising  fiixling  in  the  field  is  that  there  is  no  single  or  small  number  of  root-node  produa  metrics  that  are  always 
most  useful  to  be  examined  first  in  calculating  error  proneness.  This  varies  so  much  between  organization  practices, 
application  domains,  equipment  architectures,  test  methods,  etc.,  that  it  is  almost  impossible  to  develop  generally 
applicable  classification  tree  alr<';ithms  that  are  not  highly  parameterized  by  such  application-domain  and  other 
characteristics  of  the  setting  of  the  software  development  project  This  means  that  it  is  almost  impossible  to 
implement  a  simpler  approach  than  indicated  here  as  a  calculaiion  over  multiple  collected  measurements  —  notice 
‘hat  these  are  at  least  3  dilTerent  metnes  depending  upon  the  nnge  generated  by  the  first  metric  (the  root  node). 

Prof.  Selby's  group  is  pan  of  is  a  broad  community  that  is  building  up  empiricaJ  daabases  and  learning  about  what  the 
relevant  metrics  are  to  place  in  ctassincation  trees  under  what  circumstances,  and  thereby  refining  the  partitioning 
reflected  by  the  branching  in  the  tree.  They're  learning  by  building  up  a  body  of  knowledge  to  improve  these 
algorithms:  They’re  learning  about  application  domains  and  the  correlations  between  particular  properties  of  those 
domains  and  particular  properties  (measured  by  product  metrics)  of  software  hat  hdkateior  example,  error  proneness, 
or  reusability,  or  ease  of  change,  etc.  Given  a  set  of  characterisucs.  there's  a  growing  likelihood  that  they  have  already 
idenufiod  the  itxM-node  product  mcuic  to  compute  and  probably  the  next  level  mcuics  set  too. 

So,  there's  a  kx  of  pragmatic  analysis,  underlying  theory  and  supporting  empirical  data,  and  evolutionary  teaming  and 
expanding  capabilities  already  accompanying  Amadeus. 
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Validation  Studies 

•  Goal:  Identify  components  within  two  target  classes 

top  25%  of  faults  and  top  25%  of  effort 

•  1 6  NASA  systems 

•  Correctness:  89.6%  [=  (a+d)/(a+b+c+d)  x  1 00] 

•  Consistency:  79.5%  [=  a/(a+b)  x  100] 

•  Completeness:  69.1  %  [=  a/(a+c)  x  1 00] 


predicted  + 
total 


actual 

+ 

“a  5” 

_c _ d 

a+c 


total 

a+b 
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VAUDATION  STUDIES  (OF  THE  CLASSIHCATION  TREE  EXAMPLE) 

TTm  *****  illustrated  on  the  previous  chan  have  been  recently  validated  against 

16  W.ASA  systems:  one  predicting  top-quanile  error  proneness  and  the  other  predicting  high  effon 
upper  quamlcs  for  software  modules  entering  an  I&T  activity. 

Correctness  is  measured  as  the  sum  of  modules  predicted  correctly  to  be  error-prone  plus  those 
correctly  predicted  to  not  be  error-prone,  divided  by  the  total  number  of  all  modules  (which  includes 
those  pi^cted  wrong  either  way  as  later  deteimincd  by  integration  experience).  90%  correctness  is 

**®**^“  outstanding,  and  would  cenainly  be  welcome  predictions  for  project  management  prior 
to  a.1  I&T  acnvity.  .  r  j  o  r 

Another  approach  to  validating  the  error  or  effort  prediction  technique  is  Consistency,  measured  as 
percent  of  those  predicted  in  the  top  quanile  that  actually  turned  out  to  be.  And,  Completeness  is 
percent  of  ^lual  top-quartile  modules  that  were  identified  by  the  predictor.  Validations  of  almost 
80%  and  70%  prove  how  useful  these  algorithms  would  be  distributing  labor  during  I&T. 
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Applications:  ■.  ‘ 

:  •  Reverse  engineering 

<a,.  •  ■  , 

,•  Software  structure 
^_  -2^ev^ua^n '  - : 


Multiple  interconnection  criteria 

Multiple  visualizations  of  system 
structure 


In  one  application,  technique  was  successfully  used  to  locate  components  that  were 
six  times  more  error-prone  than  otner  components 


University  of  California,  Irvine 


INTERCONNECrrVY  ANALYSIS:  ANOTHER  AMADEUS-SUPPORTED  PROCESS  AID 


A  quick  glimpse  at  one  more  kind  of  analysis  —  Interconnecdvity  analysis. 

This  teUx  you,  given  a  "troublesome”  module,  what  other  yet-uniested  modules  are  most  likely  to 
share  die  same  troublesomeness  That's  the  essence  of  Intcrconnectivity  analysis. 

Some  Interconnecdvity  analysis  algorithms  ate  available  with  Amadeus,  and  Prof.  Selby’s  group  is 
part  of  active  research  developing  mote  such  algorithms. 
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AMADEUS  NOW: 

•  Can  provide  mechanisms  automating  Metrics  collection  today  ^ith 
current  unix-iike  platforms  (does  not  require  n  Framework' Is  used 
Integrated  SEE) 

•  Generic  interface  to  Amadeus  Measurement  Svs'iem  includes 
bindings  to  Ada  (APPL/A)  and  C  (including  shell  scripts)  now, 
demonstrating  generality  of  interface  approach  and  likely  success  of 
integration  with  other  lan9u::ges  and  tools 

•  Integrates  easily  with  independent  analysis  tools  due  to  Event-Agent 
decoupling 
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LOW  ENTRY  BARRIER 

Finally,  "low  entry  barrier"  was  an  important  objecdve  in  the  design  of  the  Amadeus  system, 
meaning  that  organizadons  can  insert  the  Amadeus  measurement  systems  into  their  development 
settings  regardless  of  the  sophistLadon  or  integiadon  existing  in  their  available  tool  platforms  or 
environments.  Stated  otherwise,  that  an  organizadon  could  very  gradually,  at  small  start-up  cost  and 
training,  insert  some  or  all  of  Amadeus's  automated  capabilides. 

Amadeus  runs  stand-alone  on  Unix- like  platforms  today.  It  can  be  instrumented  and  controlled  by 
C-shell-like  scripts  today.  The  interface  to  the  underlying  Amadeus  system  already  has  bindings  to 
Ada  (therefore  APPL/A)  and  C  today.  This  already  demonstrates  the  success  of  the  generic  interface 
approach  in  Amadeus's  design,  and  indicates  the  likelihood  that  integradon  with  other  languages, 
including  process  descripdon  languages  like  MVP,  will  also  be  straightforwardly  accomplish^  such 
further  language  integradon,  as  well  as  platform  portability,  are  being  started  as  collabomdve  efforts 
with  STARS. 

And.  Amadeus  supports  the  indtpjcndcnt  insertion  of  newly  developed  or  newly  available  analysis 
tools,  via  the  Event- Agent  senpt  paradigm  I  described  earlier.  This  promotes  both  initial  integration 
of  analysis  tools  already  in  practice  and  familiar  to  a  project  team,  and  the  expansion  of  analysis  tools 
available  to  the  team. 
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AS  OTHER  TECHNOLOGY  IS  PRODUCTIZED: 

•  Can  provide  platform  integration  approaches  to  accommodate 
migration  to  Integration  Frameworks  and  open  architecturally  for 
integration  with  other  emerging  process  capabilities 

-  STARS  SEE  area  synergy 

•  Independence  of  particular  process  languages  or  notations,  or  rather 
a  multiple-perspective  Interface  that  can  be  easily  integrated  with 
many  tools  and  languages,  is  key 

STARS  COLLABORATION  WITH  Amadeus: 

•  Developing  public  interfaces  to  Amadeus  system 

•  Will  develop  bindings  to  PCTE,  SoftBench,  ... 

•  Will  provide  test  &  validation  of  concepts  &  approaches 

•  Will  port  and  integrate  Amadeus  with  STARS  SEEs 


AMADEUS  EVOLUTION 

As  other  process  and  SEE  technology  is  proaucdzed,  Amadeus's  architecture,  based  on  the  generic 
Oanguage-independent)  interface  approaches  which  characterize  all  of  Arcadia’s  environment 
architectural  approaches,  facilitates  introducdon  of  and  evolution  to  the  highly  integrated,  synergisdc 
bamcwcrk-based  SEEs  of  the  future.  This  is  already  an  instance  of  significant  synergy  between 
STARS's  SEE  and  Process  developments  areas. 

And  additionally,  as  I  mentioned  before,  there  is  the  promise  of  interfacing  Amadeus  to  other  process 
programming  languages  and  specification  approaches  than  APPL/A  —  meaning  that  process 
engineers  might  use  statements  in  these  languages  to  indicate  where  and  what  metrics  and 
measurements  and  analyses  and  possibly  what  red-flagged  actions  are  of  interest,  and  then 
translaton  for  those  languages  produce  outputs  that  directly  or  indirectly  lead  to  Amadeus  scripts. 

I  have  already  described  a  significant  Amadeus  implementation  that  runs  today  and  is  being 
productized,  refined,  extended,  and  validated  by  current  activities  in  collaboration  with  many 
organizations,  particularly  industry.  STARS  organizations  are  pan  of  that  effort. 

Furthermore,  STARS  is  directly  supporting  several  activities  toward  productization  of  Amadeus  that 
we  have  determined  to  be  vital  to  STARS’s  objectives.  These  include  (1)  developing  documented 
public  interfaces  to  Amadeus  system;  (2)  developing  bindings  to  PCTE  and  probably  SoftBench  and 
other  framework' like  products;  (3)  testing  and  validating  Amadeus  concepts  and  approaches  via  trial 
usage  on  ffiendiy  projects  at  the  cites  of  STARS  contractors,  including  incorporation  of  in-practice 
industry  metrics  and  analysis  algorithms  back  into  Amadeus  as  possible;  and  (4)  porting  and 
integrating  Amadeus  with  STARS  SEEs.  The  first  two  of  these  activities  are  underway  now,  the 
third  has  started  via  collaboration  between  UC  Irvine  and  TRW’s  CCPDS-R  project,  and  the  fourth 
will  be  facilitated  by  the  first  two  (or  three). 
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Actionttem  Message  to  Programmer 


STARS. 


Modify  Source  Cod 
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STARS  PRODUCT:  PREIS  APPROACH 

There  are  at  least  three  prototype  STARS  products  that  you  have  heard  about  or  can  see  in  the 
demonstrations  that  incorporate  varying  aspects  of  measurement  capabiliues.  All  of  these  are 
products  being  delivered  in  the  2-year  STARS  timeframe,  and  you  already  see  the  recognition  of  the 
importance  c.'  integrating  measurement  with  these  diverse  Process-automation  products. 

The  first  is  the  prototype  EIS  system.  You  see  that  :t  obviously  has  a  set  of  collected  measurements, 
here  reflected  in  the  Action  Item  Browser's  Process  Metric  Notification  feature.  As  enactment 
occurs  in  the  Control  Point  enactment  system,  notices  in  the  form  of  Actionitems  are  sent  to  the 
appropriate  users.  Included  in  these  messages  is  information  concerning  the  product  and  process 
data  collected  during  process  execution  from  the  metric  parameters  defined  for  the  process.  This 
represents  a  fairly  fixed  set  of  metrics  associated  with  the  particular  process  definition  embodied  in 
EIS  now. 
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SPMS  Integrates  Quality  Metrics  and  Process  Models 


Adapted  from  IBM/SAIC  STARS  Work 


PSTARS  PRODUCT;  SPMS  APPROACH 
SPMS  Integrates  Quality  Metrics  and  Process  Models. 

The  RADC  Quality  Metrics  Framework  represents  13  factors  ("ilities"),  29  software-oriented  criteria, 
and  several  hundr^  metrics/questions/fonnulas  for  calculating  software  produa  quality  attributes. 
SPMS  has  stored  the  entire  RADC  ftamework  and  provides  the  tailoring  tools  so  that  a  woritable 
subset  can  be  defined  for  a  given  project.  Specific  metrics  from  the  tailor^  quality  model  can  then 
be  associated  with  the  exit  criteria  of  tasks  in  the  defined  process  model  by  the  creation  of  "data 
collection  forms"  (DCFs)  that  will  trigger  when  a  particular  task  with  such  an  exit  criteria  is 
"executed”.  The  data  input  at  that  point  will  then  be  used  along  with  the  pre-stored  formulas  to 
compute  a  value  that  is  compared  to  a  "threshold"  established  in  the  process  model  task  which  causes 
the  execution  of  the  task  to  pass  or  fail.  Failure  would  then  be  handled  by  cloning  a  rework 
networic,  etc.  Such  capabilities  are  being  provided  extensively  in  SPMS's  process  simulator. 

The  RADC  Framework  was  chosen  because  it  is  so  fully  defined,  truly  capniring  years  of  Metrics 
research  and  avoiding  time-consuming,  costly  development  on  STARS,  and  guaranteeing  projea 
usefulness  in  the  2-year  STARS  window.  But  additionally,  SPMS  intends  to  add  other  metrics 
capabilities  (for  example,  those  from  Selby  and  his  colleagues  as  done  by  Amadeus). 
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The  Geanxoom  Engineering  Process  Assistant,  implementing  a  particular  defined  process,  also 
provides  evidence  of  the  integrated  role  of  measurements  and  metrics  in  Process  Management 

So,  you  sec.  metrics  is  pervasive  in  all  good  processes  and  supponed  in  the  automation  of  good 
processes.  Metrics  and  measurement  cut  acros«  them  all.  You  should  not  be  surprised  that  il  of 
these  other  products  include  facets  of  metrics  and  measurement 

Hence,  common  underlying  support  supportive  of  many  metrics  and  analyses  but  not  necessarily 
ded  to  any  one  set  of  them,  loolb  like  a  cosi-effecdve  soludon.  That's  why  Amadeus  is  constructed 
to  be  used  the  way  I  described;  and  Amadeus  could  be  be  installed  and  integrated  with  Process 
Automadon  systems  such  as  seen  here  in  PREIS,  SPMS,  and  CEPA,  without  necessarily  changing 
any  of  the  user  screens  shown  for  those  systems,  but  offering  flexible  extensions  of  those  and  other 
user  screens  presenting  measurements  triggered  by  Amadeus  Events  and  processed  by  Agents. 
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PROCESS  MEASUREMENT 

SUMMARY 


MEASUREMENT  WILL  DELIVER 
NEAR-TERM  BENEFITS 

•  Helps  decision  makers  at  all  levels  do  their  jobs  better 

•  Low  risk  to  automate:  product  and  project  management  metrics 
collection  being  done  now  in  practice 

•  Measurement  systems  will  evolve  to  integrate  with  other  emerging 
process  technology,  e.g.,  reusable  process  assets,  process 
definition  languages  and  notations,  process  management  and 
enactment 

•  Provide  a  foundation  for  improvements  based  on  the  S£I  CMM 

The  key  to  Continuous  Process  Improvement! 


SUMMARY 

So,  in  summary,  Measurement  technology  will  deliver  near-term  benefits,  for  example,  helping 
makers  at  all  levels  do  their  jobs  better.  This  is  Process,  and  it’s  Process  improvement  within  the 
context  of  an  ongoing  project 

Extensive  measurement  represents  a  low  risk  to  automate  —  significant  automadon  of  product  and 
project  management  metrics  collection  is  in  place  now  in  practice  in  many  organizadons.  And,  it 
does  not  require  the  existence  of  a  SEE  integration  framework  to  be  able  to  use  it  now. 

Mcastneraent  systems  will  evolve  to  integrate  with  other  emerging  process  technology.’  and  process 
capabilides  you've  heard  about  in  this  track,  for  example,  reusable  process  assets,  proems  deflnidon 
languages  a^  notadons,  process  management  systems,  and  enactment  aids. 

Going  to  automated  measurement,  which  you  can  really  use  to  assess,  guide,  and  control  project 
activities,  will  provide  a  foundation  for  improvements  ba^  on  the  SEI’s  (^ability  Maturity  Model 

And,  as  has  been  stated  repeatedly;  Yoij  don't  know  what  to  improve,  or  if  attempted  improvements 
are  paying  off,  if  you  don't  have  real  measurement. 

Measuremeni  is  The  key  to  Continuous  Process  Improvemera! 
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PROCESS  MEASUREMENT 


CONCLUSION 


As  we  delve  into  this  subject  [process]  it  is  clear  that  there  is  a 
richness  and  substance  to  the  technology  that  is  barely  discernible  on 
the  surface.  In  principle  we  are  talking  about  the  design  of  processes 
that  will  permit  fallible  humans,  with  the  aid  of  machines,  to  produce 
infallible  products.  To  do  this  economically  and  to  responsively  meet 
our  users’  needs  is  a  challenge  of  the  first  order.  The  challenge  of 
software  process  research  is  thus  to  find  economic  and  effective  means 
for  applying  numbers  of  people  to  the  performance  of  complex  and 
precise  intellectual  tasks.  As  this  field  evolves,  the  technology  it 
develops  will  undoubtedly  be  of  value  to  many  other  human  activities. 

Peter  H.  Feiler  and  Watts  S.  Humphrey 
‘Software  Process  Development  and  Enactment: 

Concepts  and  Definitions” 
October,  1991  (draft) 
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IN  CONCLUSION  OF  THIS  TRACK 

I  would  like  to  read  you  an  interesting  quote  from  Peter  Feiler  and  Watts  Humphrey  in  an  SEI  report 
on  Process  concepts  and  definidons  that  will  soon  be  published. 

As  we  delve  into  this  subject  [process]  it  is  clear  that  there  is  a  richness  and  substance  to  the 
technology  that  is  barely  discernible  on  the  surface.  In  principle  we  are  talking  about  the  design  of 
processes  [ifuu's  our  Process  Definition  activities]  that  will  permit  fallible  humans,  with  the  aid  of 
machines,  [there's  our  Process  Management  or  Process  Automation  activities]  to  p^ucc  infallible 
products.  (At  least,  that's  the  vision]  To  do  this  economically  and  to  responsively  meet  our  users’ 
needs  [which  Measurement  technology  helps  us  gauge  and  determine  if  we're  succeet^ng,  ihafs  the 
essence  of  the  Quality-oriented  Product  measurements]  is  a  challenge  of  ihs  first  order.  The 
challenge  of  software  process  research  is  thus  to  find  economic  and  effective  mea.ns  [How  to  you 
know  if  they're  "economic"  and  "effective"  if  you  can't  Measure  them?  These  are  the  Productivity 
and  Predictability  objectives  of  Process  and  Project  Management  metrics]  [Also,  just  as  software 
Reuse  might  be  our  highest-leverage  software  approach,  so  this  is  the  Process  Asset  Library's 
justification,  so  we  learn  and  leverage  from  the  best  process  practices  and  achieve  economies  and 
effectiveness]  for  applying  numbers  of  people  to  the  performance  of  complex  and  precise  intellectual 
tasks  [by  carefully  defining  disciplined  processes  using  Process  Definition  languages  and 
Notations}.  As  this  field  evolves,  the  technology  it  develops  will  undoubtedly  be  of  v^ue  to  many 
other  human  activities  [outside  the  software  domain]. 
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STARS  ’91 

TRACK  2  INTRODUCTION 


’Riesday  December  3, 1991 


2.-0fr-2:45 

Domain-Specific  Reuse— Vision, 
Strategies  and  Achievements 

Ten  Payton,  Unisys  Defense  Systems,  Inc. 

2:45-3:15 

Break 

3:15-4H)0 

Reuse  Concepts 

Maggie  Davis,  Boeing 

4d>0-4:30 

Break 

4J0-5:1S 

Integrating  Reuse  into  a 

Life-Cycle  Process 

Bonnie  Danner,  TRW 

Domain  Analysis  Process 

Model 

Dr.  Ruben  Prieto-Dua,  Reuse,  Inc. 

8.-<)O-9*J0 

Community  Involvement  Working 
Group:  Domain-SpedOc  Reuse 

STARS ’91 

TRACK  2  INTRODUCTION 


Wedacsday  December  4, 1991 

U^9:1S  STARS  Asset  Libniy  Opes  Dick  Dips,  Unisyt  Dcfew  Syaont,  Inc. 

Architecture  Fruaework  (ALOAF) 

9:15-M5  Bresk 

9‘.4S-l<h30  STARS  Library  Mechanisms:  Marient  HazJe,  MITRE 

Comparisons  and  Ejcperienoes 

lO'JO-ll.-OO  Break 


lldlO-11^45  ASSET 
CARDS 


Jim  Moore,  IBM 
Rase  Amurong,  EWA 


ll:45-l»«5  Lunch 

1M5-2J0  Domain-Specific  Reuse 
Feedback  Session 


Dtfve  Ceefy.  IBM 


DOMAIN-SPECIFIC  REUSE: 

VISION,  STRATEGIES  AND  ACHIEVEMENTS 


Ten  F.  Payton 

STARS  Reuse  Architect 

Unisys  Defense  Systems,  Inc. 

3  December  1991 

(703)  620-7770/(703)  351-5308 
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DOMAIN-SPECIFIC  REUSE 

OUTLINE 


•  Problems  we  are  addressing 

•  Domain  specific  reuse  vision  and  context 

•  STARS  reuse  strategies 

•  Products  and  achievements 


r^iii 


I 

This  presenutk)n  will  begin  to  anicnlate  the  problems  that  architecture-based  domaia-speci£c  reuse  addresses.  It 
win  elaborate  the  megaprograstrning  vision  with  respect  to  domain-spedtfic  reuse  and  provide  a  top-level  view  of 
STARS  reuse  stnte^es  that  assist  in  tranatioaing  to  megaprognunming.  Highlights  of  STARS  achievements  to  date 
will  be  presented.  Currently  available  interim  reuse  products  will  be  identified.  STARS  is.  interested  in  working  with 
Technology  ‘Dansfer  Affiliate*  for  review,  tdal  usage  and  feedback  on  these  interim  products.  Subsequent 
presenutions  in  this  track  as  well  as  the  STARS  demonstrations  in  the  demo  area  wOl  provide  more  detail  on  the 
interim  products. 
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DOMAIN-SPEOTIC  REUSE 

WR4T  PROBLEMS  ARE  WE  ADDRESSING? 


i.' 

i 

Current  Problems 

Megaprogranuning  Solution 

{ 

tj 

N 

r-t 

P 

■  1 
kT 

rj 
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•  Lack  of  common  undemanding  of 
requirements  berweea  end-user 
and  developer 

•  DiScuity  in  undersanding/mainnining 
software  developed  by  someone  else 

•  DifEcuities  in  scaling  up  to  large 
development  by  many  people  with 
diversified  skills 

•  Few  incentives  to  reuse;  many  obsades 

•  New  systems  often  treated  as  unprecedented 


Architecture-based  rapid  prototyping 
with  end-user  involvement 

Well-defined  architecture  context, 
component  inier&ces  and  localizadon 
of  behavior 

Megaprogranuning  processes  and 
tedmologies  supporting  architecture-based 
reuse  and  collaborative  development 

Reuse  industry  meeting  DoD  needs 

Building  unprecedented  systems  from 
precedented  components 


The  problems  that  are  addressed  by  domain  ^pectfic  reose  are  net  simply  the  cxymmonly  recognized  issues  with 
respea  to  the  need  to  decrease  cost  or  inaease  reliability  by  reusing  existing  well  test^  software-  It  goes  much 
further  than  that  in  terms  of  grappling  with  the  underling  problems  of  buildmg  DoD  software  that  truly  meets  the 
end-user  needs.  Numerous  past  studies  have  identified  lack  of  a  common  understanding  of  requirements  as  a 
significant  problem.  Domain  ^yedfic  reuse  enables  a  change  in  the  way  we  do  business  by  facOitatidg 
architecture-based  ooiuponent-suppoited  prototyping  in  which  the  end-user  can  be  involved  prior  to  definitizauon  of 
fhe  requirements.  This  will  allow  improved  cost,  schedule  and  functionality  tradeoffs. 
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DOMAIN-SPECmC  REUSE 

VISION 


•  Guided  by  Reuse  Process 

•  Based  on  Application  Domain  Architecture 

•  Systems  Composed  From  Reusable  Assets 

•  Assets  Include  Any/All  Life-Cycle  Artifacts 

•  Supports  Continuous  Improvement  in  Reuse  Process/Products 


In  the  fntnre,  we  envision  reuse-based  software  engineering  processes  gtriding  the  developments  evolntion  of  software 
intensive  systems.  Specific  system  softwer.:  architectures  would  be  based  on  the  generic  application  rtotnam 
architecture  and  associated  gercric  requirements  set  The  system  would  be  aeated  or  evolved  using  reusable  assets. 
These  assets  can  include  application  generators,  reusable  requirements  and  tests  and  any  relevant  life-qcle  artifacts. 

The  processes  would  indnde  reuse-based  protoQrping  to  assist  in  requirements  definitization.  Both  rapid  proto^pes 
and  eventual  systems  would  be  oonqiosed  from  reusable  assets  based  on  application  domain  architecnires.  We 
envision  application  generators  to  become  inaeasingly  important  as  one  of  the  means  of  capturing  and  reusing 
application  domain  knowledge. 

A  system  may  also  includ'  reengineered  components  but  that  reengineeiing  effort  needs  to  be  done  in  the  context  of 
the  domain  architecture.  The  reengineered  components  could  then  be  provided  back  to  the  reuse  libraiy  for  usage  on 
other  programs. 
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DOMAIN-SPECIFIC  REUSE 

REAL-WORLD  SUCCESS  EXAMPLES 


There  are  several  successful  instances  within  DoD  and  external  to  DoD 
of  process-driven  domain-specific  reuse  based  development 

-  Australian  C^ 

-  Foxboro  process  control 

-  NobleTech  (BOFORS) 

-  Navy  FCDSSA  RNTDS 

-  CCPDSR 

STARS  goal; 

-  Provide  processes  and  automated  capabilities  to  enable  more  DoD 
mission  areas  to  transition  to  this  approach 

-  Work  within  the  DoD  community  to  catalyze  removal  of  political, 
cultural,  business  and  technical  barriers 


There  are  successful  instances  of  reuse  today  which  have  resulted  in  significant  cost  savings  and  quality  improvement 
for  the  organiaations  invoived.  The  list  provides  a  few  esamples  ranging  from  commercial  process  control  applications 
through  European.  Aostralian  and  American  defense  experiences.  One  item  of  significance  is  that  the  Navy  Fleet 
Combat  Directorate  Systems  Support  Activity  which  is  a  post  deployment  support  organization  has  been  snccessfni  at 
tense  in  its  maintenance  activity  on  several  ship  platforms  as  part  the  Restruaured  Navy  Ihoical  Data  Systems. 
They  have  achieved  over  80%  tense  and  significantly  reduced  the  size  cf  the  worlrforce  and  the  overall  DoD  costs  m 
evolving  these  systems. 

STARS  goal  is  to  enable  more  of  these  success  stories  in  addhional  domains  of  interest  to  DoO  by  providing 
processes  and  automated  capabilities  to  support  reuse-based  software  engineering  and  by  assisting  DoD  in 
understanding  and  addressing  the  non-techmcal  as  well  as  the  technical  barrien  to  reuse. 


7 


DOMAIN-SPECIFIC  REUSE 

STAGES  OF  REUSE 


Adapted  from  SPC  Mouot  Reuse 


The  Sofmre  Productivhy  Coosortiam  has  define  a  model  for  staged  introduction  of  reuse.  It  is  depiaed  in  the 
diagram  and  often  referred  to  as  Mount  Reuse.  Within  the  community  oui  goal  is  to  transition  from  adhoc  reuse  to 
systematic  reuse  over  time.  Most  organizatkms  are  dealing  in  adhoc  reuse  today.  Individuals  scavenge  and  find 
something  to  reuse.  Adhoc  reuse  is  based  piimanly  on  iudmdual  initiative  and  knowledge  rather  than  corporate 
knowledge  that  is  retained  across  people  and  projects. 


Organizatioos  are  beginning  to  oonstrna  ISnaiies  that  contain  multiple  i-ntcrrelated  assets  (designs,  code,  tests, 
documentation).  This  is  the  repearable  level  There  begins  to  be  a  handoff  between  the  prcdocer  of  an  asjet  and  the 
consumer  of  the  asset  The  assets  are  gathered  in  structured  libraries. 


In  the  portable  or  adaptable  level  software  oomponents  are  ^wdfically  designed  to  be  more  portable  or  usable  in 
more  general  contexts. 


The  goal  is  architecture  based  reuse  where  a  domain  analysis  has  been  perfoimed  within  the  application  domain  and 
a  degree  of  consensus  has  been  established  on  the  generic  software  architecture  and  interfaces. 

Finally,  in  the  systematic  reuse  stage,  we  can  talk  about  true  engineeiiug  of  the  domain  and  adapting  and  generating 
systems  based  on  the  architectures  and  reusable  assets. 


Domain-specifk  reuse  will  come  about  through  the  work  of  many  organizations  and  programs.  STARS  role  is 
outlined  by  the  triangle.  In  establishing  our  strategy,  we  could  have  eleo»l  to  place  all  our  emphasis  at  the 
repeatable  level  to  really  try  to  insbrutionalize  repeatable  reuse.  Instead  we  have  been  foUovnng  a  strategy  that  cuts 
across  levels.  It  provides  the  enabling  technology  for  repeatable  reuse  (library  mechanisms)  while  also  addressing 
processes  and  techniques  for  supporting  architecture-based  r^  se. 
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D0M4IN-SPECIFIC  REUSE 

STARS  REUSE  OBJECTIVES 


Establish  a  basis  for  a  paradigm  shift  to  reuse-based  software 
engineering 

•  Demonstrate  benefits  of  reuse  in  familiar  DoD  context 

•  Provide  transition  support  to  reduce  adoption  risks  in  evolving  to 
reuse-based  development 

•  Ensure  basic  reuse  processes  and  technologies  are  available  and 
validated  for  use 


Sf»a/ie 


STARS  seeks  to  establish  a  basis  to  enable  a  paradigm  shift  to  reuse-based  software  engineering  The  basis  will  be 
expanded  over  time  by  other  programs  as  the  community  raoves  forward  with  megaprogramming.  STARS  is  working 
to  accelerate  the  movement  forwaixl  To  do  this  STARS  is  focusing  on  3  main  reuse  objectives. 

STARS  will  demonstrate  the  benefits  of  domain  specific  rense.  This  will  help  the  commonity  understand  reuse,  the 
investment  costs  and  the  benefits  to  be  It  will  thus  help  motivate  others  to  invest  in  architecture-based  reuse. 

STARS  understands  that  there  are  both  technical  and  non-technical  barrien  to  reuse.  STARS  will  provide  transiaon 
support  such  as  guidelines  and  migration  paths  that  should  make  it  easier  for  others  to  introduce  reuse  into  their 
organizaaon’s  way  of  domg  business. 

STARS  will  work  within  the  community  to  ensure  there  are  well  defined  reuse  processes  and  basic  technology  (tools) 
to  mpport  reuse-based  s<  ftware  engineering.  STARS  is  developing  some  of  the  processes  and  tools  and  working  with 
others  to  leverage  their  developments. 
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DOMAIN-SPECIFIC  REUSE 

STARS  ACTIVITIES 


Establish 

Broad-Spectrum  Reuse 
Concept  of  Operations 


Establish  and 
Validate  Reuse  Library 
Open  Architecture 


Establish 
Frameworl 
for  Reuse 
Processes 


Automate 

Reuse 

Processes 


Key  STARS  reuse  activities  are  depicted  here.  STARS  is  establishing  a  framework  for  undeistanding  reuse  and  reuse 
processes  and  for  understanding  where  standards  or  common  interfaces  would  facilitate  reuse.  STARS  has  been 
working  on  several  q>ecific  reuse  processes,  e.g.,  a  domain  analysis  process  and  asset  certification  process.  STARS 
has  also  b'.en  investigating  how  to  tailor  life-cycle  processes  to  the  needs  of  specific  application  domains  and  how  to 
include  rmse  into  a  life-cycle  process.  Esamples  of  the  reuse  process  work  will  be  discussed  later  on  toda^.  STARS  is 
interested  in  automating  reuse  processes.  To  date,  most  of  the  automation  work  has  focused  on  developing  reuse 
library  mechanisms.  A  presentation  of  these  will  be  given  tomorrow  and  demonstrations  are  available  on  the  demo 
floor.  As  reuse  processes  evolve,  STARS  wiU  investigate  other  aspects  of  automation. 
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DOMAIN-SPEanC  REUSE 

STARS  REUSE  APPROACH 


Point 

Technology 

Cultural 

Insfitufenat  i  ^ 

Solutions 

EvoUAion 

Impact  - 

•  STARS  sponsored 
prototype  libraries 

-  CAMP 

-  RAPID 

•  Initial  STARS 
Repository 


•  Open  architecture 
framework  for  libraries 

•  2nd  generation  STARS 
librane« 

•  Capability  to  exchange 
assets  across  libraries 


•  Early  reuse  guidelines 

•  Reuse  concept  of 

•tinn 

■'  :  'sses 

•  .  w'.ifii  es  in 

-.r.  aure 


•  Successful  demonstrations 
of  domain-specific  reuse 
on  real  OoD  programs 

•  Commercial  technology 
to  support  reuse 

•  ASSET  fosters  reuse 
industry 


•  Integrabon  with  SEEs 

•  Processes  and  tools  to 
support  asset  creation, 
ubilzation  and 
management 


•i--  .1  hand- 

.  'blueprint* 

•  Gu  v;.  -  ;s  on  integrating 
reu.-’  (o  overall  way  of 
doing  ousiness 


•  Tailored  software 
development  plan 

•  Analyzev'publicize  success 
stories  and  lessons 
learned 

•  ASSET 


Cmmm  Spui/lt  fyOf 


The  STARS  approach  to  accelerating  the  shift  to  megaprogramming  involves  evolving  from  adhoc  point  solntions  to 
a  new  way  of  doing  business.  The  slide  depicts  the  overall  STARS  strategy  in  each  of  the  areas. 


In  the  reuse  area  we  are  currently  on  our  first  iteration  between  technology  evolution  and  cultural  impact  We  have 
created  a  reuse  process  framework,  developed  2nd  generation  library  mechanisms  and  begun  to  get  feedback  fiom 
their  usage.  We  ha«c  defined  the  basis  for  an  asset  library  open  architecture  and  begun  to  prototype  those  interfaces 
within  our  library  mechanisms.  We  have  sample  reuse  processes  and  have  recommended  changes  to  the  acquisition 
regulations  in  order  to  foster  reuse.  The  Asset  Source  for  Software  Engineering  Technology  (ASSET)  has  been 
established  as  a  focal  point  for  reuse  to  help  stimulate  a  national  reuse  indosay. 


11 


DOMAIN-SPECmC  REUSE 

REUSE  LIBRARY  RELATIONSHIPS/VISION 


•  National  Level 

-  “Yellow  Pages’’/Intcr-!ibrary  service 

-  Process  assets 

-  Multi-domain  components/algohtbms 
such  as  Ada  Bindings 

•  Interoperability  Infrastructure 

-  Network  evolution,  intercotmecdvity 

-  Open  architecture  definition 

•  Domain  Spedfic  Libraries 

-  Assets  particular  to  application  areas  or 
companies  (may  contain  common  assets) 


i 


STAP,i  envisions  that  the  future  will  involve  a  distributed  network  of  interoperating  reuse  libraries. 


There  will  be  multiple  libraries  using  different  underfying  technology  and  access  schemes  dependent  on  user  needs 
and  preferences.  Pi^ects,  organizations,  apjriication  domain;  etc.  may  each  have  their  own  library. 

There  are  some  issues  that  need  to  be  addressed  at  a  national  level  ASSET  was  established  to  address  the  national 
level  issues  and  will  provide  a  "yellow  pages"  across  mnlt^le  geographically  distributed  libiaiies. 

There  are  other  interoperability  issues  on  v^iich  consensus  within  the  community  is  necessary.  STARS  is  seeking  to 
understand  where  conunon  interfaces  are  needed  and  would  assist  the  evolution  of  a  reuse  industry.  7b  support 
interoperability  among  reuse  hbiaries  STARS  has  bettm  work  on  an  Asset  Ubrary  Open  Architecture  Framework 
which  will  be  discussed  tomorrow.  A  demonstration  of  early  capabilities  for  asset  interchange  is  available  in  the  demo 
area.  STARS  has  helped  to  establish  the  Reuse  library  Interoperability  Croup  (RIG)— an  independent  pre-standards 
group  of  over  23  organizations— that  is  working  towards  consensus  on  reuse  library  interoperability  issues. 
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DOIVLUN-SPECmC  REUSE 

PLANNED  REUSE  RESULTS 


•  Reuse  transition  support  guidelines 

•  Reuse*based  software  engineering  concept  of  operations 

•  Modular  descriptions  of  reuse  processes  associated  with  various  user 
roles  (e.g.,  domain  analyzer,  asset  certifier,  asset  cataloger) 

•  Reuse  library  open  architecture  framework 

•  Asset  library  mechanisms  that  support  the  acquisition,  classification, 
browsing,  retrieval,  and  general  management  of  reusable  assets 

•  Tools  to  support  the  reuse  process 


The  next  two  slides  identify  some  of  the  key  achievements  in  the  reuse  area.  We  have  emphasized  usage  and 
feedback  of  interim  work  rather  than  identifying  partimilar  interim  prodnets. 
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DOMAIN-SPECIFIC  REUSE 

REUSE  AREA  ACHIEVEMENTS  (1) 


•  Initial  usage  of  STARS  Library  Mechanisms 

-  AMS:  Foundation  for  NTSC  Reuse  Initiative 

-  SRL:  Supporting  early  ASSET  capability 

SAIC  Corporate  Repository 

-  RLF:  Tailored  for  NRL's  Navy  C^  Electronic  Warfare  Domain 

Being  used  in  AF  CARDS 

Internal  Unisys  alpha  programs  (e.g.,  ASW  library) 

•  STARS  reuse  process  for  domain  analysis 

-  Being  used  on  NAVAIR  Bight  simulator 

•  Example  reuse  based  life-cycle  process  tailored  to  an  application 
domain 


Sfmfit  Hi  ti’ffim  I  VCU 


STARS  is  interested  in  working  witlun  the  software  engineering  commnnity  to  catalyse  a  transition  to  rense  based 
software  engineering.  STARS  was  instrumental  in  establishing  the  RIG  and  continnes  to  actively  participate  in  RIG. 
It  is  oor  intent  that  the  STARS  ISnaries  be  npgiaded  from  compliance  with  our  own  asset  library  open  architecture 
to  compliance  with  RIG  pre-standards  as  they  become  available. 

STARS  staff  participated  in  the  JLC  San  Antonio  I  reuse  panel  to  identify  barrien  and  actionable  recommendations 
for  DoD  to  make  reuse  a  reality.  STARS  oontinues  to  work  with  the  Army  CECOM  in  supporting  the  JLC’s  efforts 
in  this  area. 

The  other  achievements  identified  on  this  slide  represent  early  STARS  work  in  providing  transition  support  and 
addressing  the  cultural  issues  involved  in  moving  to  reuse-based  development. 


DOMAIN-SPECmC  REUSE 

REUSE  AREA  ACHIEVEMENTS  (2) 

•  Catalyzing  convergence  within  DoD  community 

-  Reuse  Library  open  interface^^  for  accessing/ exchanging  assets 
-  Instrumental  in  establishing  Reuse  Library  Interoperability 

Group  (RIG) 

-  Co-chaired  JLC  San  Antonio  I  Reuse  Panel 

•  Specification  for  govemment/contractor  CDRL  library 

•  Reuse  guidelines 

•  Lessons  learned:  operational  library  management,  interactive 
certification  of  components,  and  AFS  usage 

•  Intensive  interviews/synopsis  report  across  most  government  reuse 
efforts 

•  Recommendations  for  FAR/regulation  modifications  supporting  reuse 

•  ASSET  began  operations 

Tfiiylr  KmmJrmimilVCl} 


A  high  level  view  of  final  STARS  reuse  prodocts  is  provided  by  this  slide.  Interim  versions  of  the  products  will 
receive  trial  use  within  alpha-test  projects  by  the  Primes,  in  the  demonstration  prefects,  in  the  AF  CAROS  program 
and  by  Technology  Transition  Affi^tes.  The  final  products  will  reflea  the  feedback  firom  this  usage.  The  STARS 
reuse  products  address  both  an  evolution  of  the  technology  base  and  transition  support  guidelines  that  help  address 
the  cultnial  issues  involved  in  moving  towards  a  new  of  doing  business. 
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DOMAIN-SPECinC  REUSE 

REUSE  PRODUCTS  AVAILABLE  NOW 

Point  Solutions 

•  Prototjpe  Libraries 

-  Software  Reuse  Library  (limited  distribution) 

Products  Supporting  Technology  Evolution 

•  Reuse  Processes 

-  Domain  Analysis  Process 

-  Asse;  Certification  Process 

•  Standards/Conventions 

-  Asset  Library  Open  Architecture  Framework 

•  Second  Generation  Library  Mechanisms 

-  Reusability  Library  Framework  (public  distribution) 

-  Asset  Management  System  (beta  InQuisiX  license  from  SPS) 

V I  Hi  ■!  ■  I 


The  interiin  prodocts  listed  on  these  rwo  slides  are  organized  according  to  the  stage  of  the  STARS  approach  the 
product  supports.  Thus  they  are  characterized  as:  point  solntions,  products  supporting  technology  evolution  and 
products  supporting  cnltnial  change. 

Farther  information  on  the  processes,  toob  and  reports  listed  on  these  slides  can  be  found  in  the  STARS  Catalog  or 
the  remainder  of  the  presentations  at  STARS  *91.  Many  of  the  documents  identified  on  the  nea  two  slides  will  be 
handed  out  to  you  today.  All  of  the  library  mechanisms  are  being  demonstrated  in  the  STARS  booth.  We  invite  yon 
to  join  with  us  in  accelerating  the  transition  to  megaprogramming  by  working  as  Technology  Iransition  AfiHitates  and 
provtduig  us  feedback  on  these  early  products. 
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DOMAIN-SPECIFIC  REUSE 

REUSE  PRODUCTS  AVAILABLE  NOW 


Products  Supporting  Cultural  Change 

•  Transition  guidelines 

-  Reuse  Concept  of  Operations 

-  Composite  Process  Model  integrating  reuse 

-  Sample  process  tailoring  to  application  domain  risks 

-  Reusable  Software  Acquisition  Environment  report 


REUSE  CONCEn  S 

OUTLINE 

•  Reuse  perspective  on  STARS  vision 

•  Reuse  process  conceptual  framework 

•  Benefits 
-  Content 

•  Domain  concept 

•  Next  steps 

n*ua*Ccra«pa/0«<m/VG2 

This  uDc  fives  an  overview  of  the  reose  perspective  on  the  STARS  visioo  with  regard  to  specific  tenns  of  the  vision 
smemetu  and  widi  regard  to  the  reuse  concepts  documrrn. 

This  talk  will  describe  assuxnptioos  and  benefits  of  the  reose  process  cooceptual  fiamework  as  well  as  describe  what 
the  framework  contains. 

The  final  topic  will  address  what  we  believe  are  the  logical  neat  steps  in  evolving  and  refining  reuse  concepts  for 
STARS. 


* 
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REUSE  CONCEPTS 

REUSE  PERSPECTIVE  ON  STARS  VISION 


PROCESS-DRIVEN 

Well-defined  and  consistently  applied 
processes  for  creating,  managing, 
reusing  assets 

REUSE-BASED 

Derive  new  and  modified  systems  from 
existing  assets 

D0M4IN-SPECIFIC 

Assets,  processes,  technology  are 
appropriate/tailored  to  domain  (s) 

TECHNOLOGY-SUPPORTED 

Substantial  automated  support  for 
processes; 

Assets  and  tools  integrated  into  SEE 

COLLABORATIVE- 

DEVELOPMENT 

Assets  shared  among  geographically 
-dispersed  libraries  on  heterogeneous 
platforms 

Being  PROCESS-DRIVEN  means  tbat  software  engineering  is  done  in  accordance  with  well  defined  processes  ihat 
are  consistently  applied.  Support  for  guidance,  monitoring,  and  de&nidoo  of  processes  is  provided  by  the  software 
engineering  enviromneni. 

Being  REUSE-BASED  means  that  the  standard  approach  to  software-intensive  system  development  and  evolution  is 
to  derive  new  and  modified  systems  principally  ^m  existing  assets  rather  than  to  create  them  anew.  Note,  this 
approach  requires  that  relevant  assets  be  available,  as  well  as  processes  defming  how  to  use  the  assets  to  produce 
systems.  The  reusable  assets  anutned  to  be  available  include  not  only  the  software  components  most  commonly 
associated  with  reuse  but  also  addidooal  kinds  of  information  such  as  requirements,  specifications,  architectures, 
designs,  test  procedures,  domain  knowledge  models,  data  dictionaries,  algorithms,  process  definitions,  and  rationale. 

Being  DOMAIN-SPECIFIC  means  that  the  reusable  assets,  the  developmem  processes,  and  the  supporting  technology 
are  appropriate  to,  perhaps  tailored  for.  the  docaam  in  which  the  software  is  being  developed.  We  believe  that  the 
same  reuse  concepts  and  the  same  generic  processes  and  technology  apply  to  <totnain<  of  various  types  and  levels. 

Being  TECHNOLOGY  SUPPORTED  means  tbat  there  is  substantial  automated  support  for  the  reuse  processes. 
Further,  the  reusable  assets  and  the  support  tools  are  imegrated  in  the  software  engineering  environment  being  used. 

Doing  COLLABORATIVE  DEVELOPMENT  means  that  reusable  assets  can  be  shared  among  libraries  that  are 
geographically  distributed  and  hosted  on  beterogeneous  platforms.  Tbe  vision  is  that  a  user  can  use  a  single  interface 
to  interact  with  all  libraries,  unaware  of  whether  or  not  an  asset  comes  from  a  local  or  remote  library  and  of  the 
particulars  of  the  user  interface  or  of  die  data  model  assoaaxed  wnh  the  onginaong  library. 
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REUSE  CONCEPTS 

CONCEPT  OF  OPERATIONS  DOCUMENT 


DOES: 


Elaborate  on  reuse  VISION 

Define  conceptual  FRAMEWORK  for  reuse  processes 
Establish  common  reuse  VOCABULARY 


DOES  NOT : 


•  Prescribe  THE  way  to  do  reuse 


WILL: 


•  EVOLVE  over  time 

-  Review 

-  Feedback  from  use 


1  rwnCnui  i  yWiOma/VG* 


Tbe  STARS  rras«  concept  of  operadoos  doemnent  is  the  first  step  ia  providing  guidance  on  bo«'  to  evolve  leuse- 
based  approaches  and  in  making  sure  that  appropriate  reuse  support  capabilities  are  known.  Thus,  the  document 
aniculati»  STARS  coocepu  and  e;tpectadoQs  for  reuse  with  respect  to  system  and  software  development  by: 

-  elaborating  on  the  STARS  reuse  vision; 

-  defining  a  framework  for  defimdon  of  reuse  processes: 

-  esublishing  a  rntrimfin  STARS  terminology  for  reuse; 

-  addressing  the  impaa  and  oppommities  for  use  of  distributed,  heterogeneous  asset  libraries  as  a 
reuse-enabling  technology  (tins  topic  will  be  covered  in  the  foUowmg  session  of  the  Reuse  Track); 
and. 

-  providing  a  contest  for  understanding  STARS  reuse  plans  and  product. 

Tbe  STARS  reuse  corcepts  joim  acnviiy  team  believes  that  there  is  no  one  'right'  software  development  process  that 
appbcable  to  all  organizauons.  applicanons,  p>  ejects,  or  mstl^xlologies.  Thus,  the  reuse  concept  o.'  operations 
document  does  NOT; 

-  provide  a  concept  of  operacoos  for  a  tool  software  development  process; 

-  provide  a  concept  of  op^nuoos  for  a  specific  organizatioo;  or 

-  prescribe  "the"  way  tr  do  reuse. 

We  expect  lo  release  version  1.  volume  I  in  January  1992.  This  new  version  svill  reflect  technical  review  by 
individuals  inside  and  outside  of  STARS.  Funhermore.  we  expect  to  conunuously  evolve  this  volume  as  other 
organizations  provide  feedback  from  reading  it  and  from  trying  to  use  it  as  guidance.  Volume  II,  which  will  contain 
elaborations  on  the  processes  svithin  the  reuse  process  framework  will  be  incrementally  released  as  process 
desenpuons  become  available.  It  is  our  hope  that  these  two  volumes  will  be  used  by  those  technologisu  who  aeate. 
monitor,  odmiajter,  and  mo<i!i>  systems  and  software  development  and  maintenance  processes. 
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REUSE  CONCEPTS 

PRIMARY  BENEFITS  OF  FRAMEWORK 


•  Adaptable  to  different : 


-  Goals 

-  Organizations 

-  Projects 

•  Common  viewpoint  for  reuse  processes: 

-  Discussing 

-  Defining 


RoueC«Deepa.Orai/VC5 


To  reioforce  our  belief  that  there  is  not  one  way  to  do  reuse,  the  reuse  concepts  joint  activity  team  explicitly 
developed  the  reuse  process  framework  to  be  generic,  and  thus,  adapuble  with  respect  to  its  application  by  spec^ic 
organizations,  within  specific  methodologies  or  approaches,  or  as  supported  by  a  specific  software  engineering 
environmenh 

It  is  our  intent  that  the  reuse  process  framework  will  aid  in  understanding  the  technical  issues  involved  m  integrating 
reuse  throughout  a  system  or  software  life  cycle  process.  This  assistance  is  a  ccnsequence  of  the  framework 
providing  a  common  viewpoim  for  discussing  and  defining  reuse  processes. 

We  expect  that  this  framework  will  be  of  interest  to: 

-  Software  Program  Managers  in  understanding  how  reuse  may  affect  the  development  process  and 
be  incorporated  into  project  planning; 

-  Acquisition  Plannerr  who  plan  acquisition  strategies  and  prepare  request  for  ’^ropocal  fRFP) 
packages; 

—  Acquisition  Policy  Makers  who  are  teekmg  to  better  understand  how  to  fester  reuse;  and, 

--  Process  Engineers  developing  coinposable  reuse  processes  and  merg-ng  them  into  larger  process 
contexts  such  as  life  cycle  models. 


REUSE  CONCEPTS 

REUSE  PROCESS  FRAMEWORK 


MASXrr  FORC3S 
ASSETS 

EXISTING  SYSTEMS 
DOMAIN  EXTESnSE 
TOOLS 
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The  STARS  Reuse  Process  Framework  ide-nrifies  fuacdoo*  and  processes  supportisg  reuse  in  the  context  of  software' 
intensive  system  development  and  maintenance.  The  framework  has  been  organized  into  four  families  of  processes, 
whose  names  emphasize  the  primary  purpose  of  each.Tbe  arrows  in  the  figure  represent  the  extensive  irifotmation 
(low,  influence,  and  feedback  among  the  four  process  families.  In  general,  the  arrows  represent  the  flow  of 
decisions,  constraints,  experience  lessons,  and  assets. 

The  families  of  the  reuse  process  framework  can  be  decomposed  further  to  identify  processes  and  functions  focusing 
on  different  aspects  of  each  family's  purpose.  In  the  viewgraphs  following,  I  will  describe  the  dec(  ^position  we 
used  in  the  doonnenL  However,  the  reuse  concepts  joint  activity  team  recognizes  that  individual  organizations  may 
use  difiereni  decompositions  of  these  families  to  suit  their  goals  and  business  strategies. 

Planning  processes  set  goab  and  strategies,  select  and  effect  the  tailoring  of  processes  consistent  with  the  goals  and 
strategies,  and  identify  and  allocate  existing  resources.  The  asset  creation  process  family  produces  software  and 
software  related  assets.  The  asset  management  process  family  svaluaies,  describes,  and  organizes  the  assets  provided 
by  the  asset  creation  jTocess  family.  The  asset  utilization  process  family  accesses  the  organized  assets  to  consima 
software-intensive  systems. 

Lessons  learned  regarding  the  usage,  applicability,  quality,  and  reusability  of  assets  are  feedback  from  the  asset 
utilization  processes  to  the  asset  management  processes.  Lessons  learned  regarding  missing  assets  or  possible  asset 
leneralizauons  are  feedback  from  the  asset  utilizauon  processes  into  ‘die  astxt  aeanon  processes.  Lessons  learned 
regardmg  asset  quality  and  description  are  feedback  from  the  asset  mauagement  processes  to  the  asset  aeaticn 
processes.  Needs  for  new  assets;  lessons  learned  regarding  process  usage,  applicability,  and  quality;  and  new  process 
assets  are  feedback  from  the  asset  aeation.  asset  managemenx,  and  asset  utilization  processes  into  the  asset  planning 
processes. 
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REUSE  CONCEPTS 

FRAMEWORK  SUPPORTS  MULTIPLE 
REUSE-BASED  LIFE  CYCLE  MODELS 


Supports  composition  of  reuse  processes  into  different  life  cycle  models 


-  Independent  of  life  cycle  model  styles 


-  Examples: 


SPIRAL 


Domain  development  &  evolution 
System  integration 
System  evolution 


HistOTically.  orginizanons  have  based  ibeir  software  developmcni  plans  on  methodology,  technique, 
or  tool  selecdoos  made  to  implement  an  idealized  project  life  cycle  rather  than  on  composable  process  selections. 
Indeed,  software  development  has  mostly  been  ccmsidered  as  one  gigantic  waterfall  life  cycle  ^vided  into  major 
phases  encompassing  system  conception  to  demise.  In  contrast,  STARS  is  promoting  the  concept  that  there  are 
m'lluple.  valid  modem  software  life  cycle  models  appropnaie  for  different  organizational  goals,  strategies,  and 
strengths.  That  is.  STARS  is  generalizing  the  concept  of  life  cycle  model  from  a  strategy  for  software  SYSTEM 
deveiopmem  to  strategies  for  software  PRODUCT  development,  where  product  includes  components,  interface  and 
protocol  standards,  architectures,  domain  models,  applicatioo  generators,  and  systems. 

We  expect  (hat  the  reuse  process  frameworlt  will  be  used  to  guide  composition  and  instantiation  of  reuse- 
based  sofnvare  life  cycle  models  by  selecting  compatible  processes  from  among  its  process  families.  The 
processes  selected  should  be  compatible  among  themselves,  with  organizational  goals,  strategies,  and 
strengths,  with  project  requirements  and  constraints,  and  with  characteristics  of  the  domain. 

Please  note  that  the  reuse  process  framework  is  also  independent  of  any  particular  life  cycle  model  style.  By  style, 
we  mean  the  model's  strucairu  with  respect  to  elapsed  time,  such  as  waterfall  or  spiral.  The  framework  has  no  pre¬ 
defined  entry  point  but  it  does  indicate  what  information  frows  among  the  process  families. 

Some  example  reuse-based  life  cycle  models  are; 

-  Domain  Development  and  Evolution,  whose  goal  is  production  and  evolution  of  reusable  assets  in  a 
single  donum; 

-  System  Integration,  whose  goal  is  constructing  new.  complex  software-intensive  systems  that  are 
integrations  of  reusable  assets  from  multiple(sub)domains;  and. 

-  System  Evolution,  whose  goal  is  nuintainmg  the  viability  of  a  system  as  its  underlying  domain  and 
solution  technology  mature  and  evolve. 
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REUSE  CONCEPTS 

BENEHTS  OF  ^TLL-DEFINED. 
COMPOSABLE  PROCESSES 


•  Tailorable  for 


-  Organization 

-  Domain 

-  Project 

•  Discrete  unit  facilitates 

.  Management 

-  Measurement 

•  Improvement 

•  Identify  similarities  among  processes 

-  Reuse  of  technology 

•  Reuse  of  engineering  skills 


There  is  one,  very  basic  assumpoon  underlying  the  reuse  process  framework.  The  assumption  is  that  processes  can 
be  defined  in  DISCRETE,  WELL-DEFINED  units  that  can  be  composed  into  broader  contexts.  This  is  the  reuse 
technical  area's  leverage  point  with  STARS  process  technical  area. 

We  believe  the  benefits  of  this  assumption  lo  be: 

-  Easier  implementation  and  tiiloring  of  life  cycle  models  in  support  of  individual  domains, 
(ffganizations,  and  engineers. 

-  Simplified  management,  measurement,  monitoring,  and  improvement,  of  life  cycle  model 
implementations  and  improvement  in  life  cycle  models. 

-  Ideodficaiion  of  the  stmilarities  in  appropriate  methods,  techniques,  and  tools  supporting  various 
life  cycle  models  and  processes. 

-  IdentificaticBi  of  similarities  among  required  engineering  skills. 

Tbese  benefits  accrue  because  discrete,  composable  processes  are  easier  to  define,  may  have  formal  represemaiions. 
have  definite  begin  and  end  points,  have  de^ie  start  and  stop  enteria,  span  a  shorter  time  durauon  than  life  cycle 
phases,  and  can  be  customized  to  available  tools  and  environment  support. 
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REUSE  CONCEPTS 

REUSE  PLANNING  PROCESS  FAMILY 


ORGANIZATION 

STRATEGIES 

PROJECT  PLANS 

PROCESSES 

LIFECYCLE 

MODELS 

COALS 


t  ■■aTfiiiHin  l>«yu/VG» 


An  important  function  of  the  planning  activity  in  (be  reuse  process  framework  is  to  define  a  reuse  strategy  and  plan 
for  its  implementation  within  the  organization  that  is  uzidertaJdng  a  reuse  program.  A  second  function  is  to 
implement  (be  strategy  in  plans  and  processes  for  a  specific  projecL  A  related  funenoo  is  to  measure  and  evolve  the 
process  for  exeaiting  the  plans.  Note  (bat  many  of  (be  planning  activities  and  products  aie  appropriate  at  both  the 
organizatiooal  and  spwxific  projea  levels. 

Reuse  Strategy  Development:  A  reuse  strategy  is  used  to  guide  the  asset  creation.  managemenL  and  utilization 
processes.  The  activities  required  to  define  the  strategy  will  depend  on  the  nature  of  the  organization,  e.g.,  whether 
it  is  a  company  seeking  to  market  reusable  components,  or  develop  systems  based  on  them,  a  DoD  Program 
Executive  Officer  establishing  a  reuse  program  for  a  ^ven  dom;>’'  ^gram  Manager  developing  a  specific 
system,  or  a  maintenance  Tganization.  The  strategy  will  be  infi  y  organization's  goals  and  top  level 

reuse  policy.  Tbe  reuse  strategy  may  define  processes  that  identify.  ev,Maate  and  selea  domains  for  reuse;  define  a 
set  of  methods  for  asset  rreaaon  that  are  compatible  with  the  methods  for  asset  utilization;  create  plans  for  asset 
creation,  management,  and  utilization;  and  defme  goals  to  measure  the  effectiveness  of  reuse.  A  software  reuse 
straregy  may  mclude.  but  is  not  limited  to.  a  domain  selection  method,  an  asset  creation  plan,  an  :-s$et  management 
pian.  an  asset  unlizaucm  plan,  and  process  and  product  improvement  plans. 

Process  &  Product  Improvement  planning:  The  reuse  process  measurement  and  evolution  function  receives  input  in 
tbe  form  of  dau  captured  about  the  asset  creation,  management,  and  utilization  processes  and  products.  It  also 
receives  lessons  learned,  asset  requirements,  process  requirements,  and  any  other  form  of  relevant  feedback  from 
individuals  involved  in  (hose  processes.  Feedback  fiom  the  users  of  the  software  products  is  also  input  to  this 
funcuon. 
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REUSE  CONCEPTS 


ASSET  CREATION  PROCESS  FAMILY 


i  ^ 


PLANS 

N-EEDS 

LESSONS 

PROCESSES 

'RISOVRCLS 
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The  goal  of  IXDMAIN  ANALYSIS  is  to  develop  a  domain  modeU  reusable  requirements,  and  domain  variability 
description  applicable  to  solution  systems  within  the  domain.  Note  that  domain  is  being  used  here  in  its  broadest 
sense,  i.e.  as  an  area  of  activity  or  knowledge.  At  a  high  level,  domain  analysis  is  a  combination  of  reverse 
engineering,  knowledge  extraction,  technology  and  requirements  fmecasting.  and  modeling. 

The  purpose  of  SOFTWARE  ARCHITECTURE  DEVELOPMENT  is  to  produce  an  architecmrc  that  can  be  used  to 
implement  numerous  systems  for  the  dntnain  as  defmed  by  the  domain  analysis. 

The  goal  of  SOFTWARE  COMPONENT  DEVELOPMENT  is  to  develop  reusable  software  components  that 
implement  the  previously  developed  domain-specific  architecture.  Before  this  activity  is  undertaken,  reuse  planning 
has  already  evaluated  whether  component  development  L>  more  appropriate  than  or  complementary  to  application 
generator  development  or  use.  Reuse  planning  activities  will  also  have  evahiattd  whether  translation  of  code  from 
legacy  systems  may  also  be  appropriate. 

The  goal  of  APPLICATION  GENERATOR  DEVELOPMENT  is  to  provide  a  capability  that  allows  a  reuser  or 
applicaDOD  developer  to  aeate  software  (sublsystems  using  the  coacepts  and  terms  belonging  to  the  domaia  The 
poini  is  to  suppon  the  end  user  m  sucing  "what"  is  desired  rather  than  detailing  "bow"  the  desired  effect  is  to  be 
achieved.  This  "what"  cnetuaaoD  can  also  be  termed  requiremenis-based. 

The  goal  of  ASSET  EVOLLTION  is  to  respond  to  the  feedback  of  asset  evaluations  from  the  asset  management  and 
asset  utilization  processes.  There  should  be  expliat  processes  that  receive  and  analyze  this  feedback  with  the  objective 
to  enhance  the  appropriate  domain  model,  software  architecture  and  components,  and  appUcauon  generators.  The 
feedback  may  also  be  used  to  improve  or  better  uilor  the  processes  of  modeiing,  component  and  architecture 
creaticQ,  and  application  generator  ^velopment  to  the  needs  of  parucuJar  domains  at  organizations. 
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Domains  have  been  cbaracterized  as  applicahoo,  horizontal,  or  vertical,  teclmology,  computer  science,  execution, 
execntioa  models,  etc..  The  figure  grapUcally  depicts  relationships  among  some  characterizations  of  doinains. 

In  the  figure,  application  doinains  represent  the  Imowledge  and  concepts  that  pertain  to  a  particular  computer 
application  area  such  as  battle  management,  avionics.  C3I,  and  nuclear  physics. 

Mid  left  on  the  figure  is  a  depiction  of  a  vertical  domaixi.  A  vertical  domain  is  a  rcpresentatim  of  the  the  essential 
fuDctionality  of  a  restricted  set  of  systems  that  pertain  to  a  particular  member  of  an  application  (sub)domain.  This 
fignre  also  attempts  to  show  that  a  domain  model  sbo'ild  be  related  to  one  branch  of  a  vertical  decomposition  of  an 
application  domain. 

At  the  bottom  of  the  figure,  borizontal  doinains  are  depicted  as  the  knowledge  and  concepts  that  pertain  to  a 
particular  functionality  of  a  set  of  software  components  that  can  be  utilized  across  more  i^an  one  application  domain. 
Example  horizontal  domains  include  user  inieifaces,  database  systems,  and  statistics.  Most  horizontal  rfnmainc  can  be 
decomposed  into  a  tree  or  family  of  more  sp*cialized  (sub)domains  where  the  decomposition  is  guided  by 
charactertsucs  of  the  soluuon  software.  Distinguishing  characteristics  may  be  software  decomposition  style 
(functional,  oOject-oriented,  dau-onented,  control -oriented,  declarative,  etc.),  conceptual  underpinning  (relauonal. 
hierarchical  dau  models),  or  paruculir  requirements  for  hardware  oi  performance  characteristics.  These 
requirement  characterizauons  may  be  used  to  relate  particular  sets  of  software  components  to  a  specific  domain 
model  for  instantiation  in  a  desired  system. 

The  reuse  concepts  jomt  atuvity  team  agrees  this  is  very  complicated.  We  have  attempted  to  develop  a  simpler  view, 
and  will  continue  to  do  so  We  feel  that  reaching  a  consensus  on  what  we  mean  by  domain  contributes  to 
understanding  where  and  how  donum  modelmg  and  analysis  fits  mto  reuse-based  development. 
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Tbe  goal  of  asset  ACQUISITION  is  to  obtain  assets  from  external  asset  libraries  and  other  sources  in  support  of 
asset  creation  and  asset  utilization  activities. 

Tbe  goal  of  asset  ACCEPTANCE  is  to  ensure  that  an  asset  satisfies  all  legal  and  policy  constraints  and  that  sufficient 
informahoo  is  available  to  catalog  the  asset 

The  goal  of  asset  CLASSIFICATION  is  to  develop  a  scheme  for  categorizing  assets  on  the  basis  of  tbeir  domain- 
relevant  characteristics.  The  classificatiaa  scheme  provides  libra^  users  with  an  organizational  framework  for 
locating  and  undenunding  domain  assets. 

Asset  CATALOGING  is  broken  down  into  three  steps;  asset  categorizahon,  asset  description,  and  asset  installahon. 
Asset  CATEGORIZATION  is  the  process  of  detemuniog  where  an  asset  belongs  within  the  classification  scheme. 
Asset  DESCRIPTION  is  the  process  of  creating,  capturing,  or  adapting  all  tbe  information  that  is  needed  to  describe 
the  asset  in  the  context  of  the  library's  data  model,  once  the  asset  has  been  categorized.  Asset  INSTALLATION  is 
the  process  of  installing  the  categorized  and  described  asset  in  ihe  library  system. 

The  ultimate  goal  of  asset  CERTIFICATION  is  to  guarantee  that  software  assets  implement  their  requirements  and 
that  their  execution  will  be  error  free  in  their  intend^  cnvironmenL 

Tbe  goal  of  LIBR  JIY  AND  ASSET  METRICS  COLLECTION  is  to  improve  the  effectiveness  of  the  library  in 
supporting  reuse  processes  within  client  organizauons. 

The  goal  of  LIBRARY  ADMINISTRATION  and  operahon  is  to  assure  ihe  availability  of  the  asset  library  for  asset 
aeahoD  and  asset  utilization  activities. 

The  goal  of  the  asset  MAINTENANCE  and  enhancement  process  is  to  iteratively  improve  the  assets  in  the  library 
relative  to  user  and  domain  needs. 
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There  are  two  primauy  methods  of  asset  udlizatioo.  correspondinf;  to  system  composition  and  system  generatioa 
These  two  asset  utilization  methods  are  complemeoiaiy  and  can  l:oih  be  employed  within  the  same  dfimain  or  for  a 
single  system  development.  The  other  processe*^  shown  here  (asset  identification,  asset 
onderstandin^evaluation/selectioo.  and  asset  tai]oringhntegr>uoa)  each  have  the  same  goals  but  are  are  approached 
differently  within  each  utilizanon  method. 

Asset-based  system  COMPOSITION  is  a  process  in  which  the  software  engineer  constructs  new  products  (e.g., 
requirements,  design,  code,  tests,  documentation)  from  previously  developed  or  newly  generated  parts.  This  is 
typically  done  by  identifying,  understanding,  evaluating,  and  selecting  appropriate  generalized  domain  assets  and 
tailoring  and  integrating  them  to  meet  specifK  system  needs. 

System  GENERATION  is  a  process  for  producing  systems  or  subsystems  that  ideally  incorporates  all  the  variation  in 
a  domain  into  a  set  of  parameten  expressed  in  terms  of  a  specification  language  or  template.  A  generation  tool 
accepts  specifications  from  engineers  that  define  values  for  the  domain  parameters  and  resolves  the  vari  .tion 
accordingly  to  generate  components  of  the  target  system. 

Asset  utilization  may  reveal  the  need  to  amend  the  domain  model,  to  consmict  new  assets,  and  other  or  t't  change  or 
delete  other  assets.  Similarly,  each  reuse-based  development  effort  should  yield  lessons  that  can  be  applied  to  asset 
management  within  the  domain.  Engineers'  experiences  with  browsing  and  querying  the  library  may  result  in 
recommendanons  for  refining  or  correcting  aspects  of  the  library  taxonomy  or  asset  descriptions;  experiences  with 
the  tools  used  to  facilitate  asset  undcntanding,  tailoring,  integration,  and  generation  may  yield  recommendations  for 
additional  tools  or  improvements  to  the  existing  tools;  problems  with  assets  that  were  thought  to  be  well-qualified 
may  reveal  inadequacies  in  the  asset  qualificauon  process;  lack  of  adequate  access  to  the  remote  libraries  may  result 
in  recommendations  for  improved  library  connectivity  or  interoperability. 
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NEXT  STEPS _ 

•  In-depth  review  of: 

-  Framework 

-  Vocabulary 

•  Develop/acquire: 

-  Processes 

•  Lifecycle  models 

•  Construct  volume  n  of  reuse  concepts 

•  Elaboration  of  process  categories 

•  Feedback  and  trial  use 

•  Construct  process  descriptions 

•  Reuse  adoption  handbook 

tajwCgariya/DivSi^GU 


We  have  reached  the  fitiil  viewgraph  ia  this  presentation.  We  want  to  tell  yon  where  we  thinir  we  go  from  here. 

We  will  be  improving  and  refining  both  the  framework  and  the  set  of  fundamental  terms.  We  invite  and  would 
welcome  review  by  you.  Verson  0.5  of  the  Reuse  Concepts  doaimcnt  is  available  here  tooay  to  facilitate  your 
participaiico. 

We  will  be  developing  or  acquiring  composable  process  definitions  and  life  cycle  models.  Contributions  from  you 
and  yonr  organizations  wcwld  be  most  wdcome.  They  may  also  be  to  the  process  asset  library  being 
in  the  process  track. 

Our  immediate  next  step  is  to  construct  volume  n  of  the  reuse  concepts  document.  This  volume  will  elaborate  on 
processes  we  have  identified  in  the  decoopositioo  we  used  in  volume  I.  It  will  also  elaborate  on  the  considerable 
flow  of  information  shared  among  diflereru  process  families.  This  is  again  an  opportunity  for  you  to  provide  us 
with  feedback  and  rucotnmendatiaos. 

Results  from  DSD  Laboratories  and  the  CARDS  program  will  be  used  in  developing  a  tense  adoption  handbook  chat 
addresses  the  non-technical  bamen  to  reuse. 
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Under  STARS  tasking,  we  integrated  software  development  reuse  acnvities  into  a  risk -driven,  spiral-based  process 
model.  We  also  initiated  the  adapianon  of  the  reuse-based  process  to  a  specific  application  domain. 

This  work  is  documented  in  two  separate  reports: 

1)  STARS  Subiask  IJS<0.2  Composite  Paradigm  Report  for  Software  Technology  for 
Adaptable  Reliable  Systems 

2)  US40  -  Risk-Reduction  Reasoning-Based  Development  Paradigm  Tailored  to  Navy  C~ 

Systems 

Copies  of  these  reports  are  here  on  the  table  and  will  be  available  today  after  the  briefings. 
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OUTLINE 


•  Adaptation  for  Reuse  and  Domain  Tailoring 

•  STARS  Reuse  Framework  Integration 

•  Composite  Process  Model  Foundation  and  Key  Elements 

•  Assumptions,  What  It  Is/Isn’t 

•  Overview  of  The  Process  Model 

•  A  Closer  Look:  Quadrants  and  Sectors 

•  Domain  Tailoring  Example 

•  Conclusions 


This  briefing  provides  an  overview  of  reuse-based  process  model  enhancements  and  an  initial  domain  tailoring  of  the 
life-cycle  process  descripdoris.  We  will  examine  the  process  model  foundation  and  the  composition  of  the  integrated 
process.  We  will  then  review  the  domain  tailoring  example  and  discuss  conclusions  and  recommendations. 
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For  ihe  STARS  Program  Unisys  uslcing,  we  adapted  previous  TRW  process  modeling  work  under  the  DARPA 
SISTO  project.  Advanced  Computing  Systems  (ACS).  The  Composite  Process  Model  is  a  risk -driven,  reuse-based 
process  model  for  high  assurance  softwatre  development  The  model  provides  an  initial  framework  for  specific 
process  acdvitics  and  embeds  reuse  into  the  spiral  based  paradigm.  Task  goals  for  the  Composite  Process  Model 
were  to  integrate  STARS  reuse  processes  into  a  full  life-cycle  paradigm,  to  adapt  previous  DARPA  work,  to  provide 
a  foundauon  for  more  detailed  reuse  process  descriptions,  and  to  provide  top  level  guidance  for  reuse-based  process 
desenpuons  in  a  risk -driven  paradigm.  The  model  represent  an  interim  step  toward  broad  STARS  goals  for  domain- 
specific  reuse  as  an  element  of  megaprogramming  support  This  task  illustrates  the  integration  of  reuse  into  a  life¬ 
cycle  process.  Current  reuse  and  process  efforts  and  the  STARS  reuse  process  framework  provide  input  into  major 
spiral  stages  of  activity.  As  an  mienm  step,  the  Composite  Process  Model  is  applicable  to  fuuire  domain-specific 
process  modeling.  For  this  tasking,  the  model  has  been  combined  with  preliminary  Navy  C^  domain  analysis  work 
to  defme  a  domain  specific  process  model.  The  focus  of  the  resulting  model  is  domain  specific;  however,  the  overall 
paradigm  has  more  general  application  as  a  process  model  represenuiion.  In  addition,  reuse  process  model 
represenujuon  experiments  were  niuaied  under  this  tasking. 
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The  fundamental  reuse  process  acnviucs  that  make  up  the  STARS  reuse  process  framework  were  interpreted  tor 
project  implementation  and  integrated  into  the  nsk -driven,  life-cycle  spuaJs  of  the  TRW  DARPA  ACS  Process 
model.  Project  reuse  acovities  were  idendfied  for  each  of  five  major  spirals  for  high  assurance  system  development. 
These  spirals  will  be  discussed  later  in  this  briefing.  The  spiral  basis  for  the  Composite  Process  Model  is  illustrated 
here  with  circular  clockwise  rotations  around  four  defined  quadrants  of  activities.  Spiral  activities  are  iniiatcd  in 
v^uadrant  L  Starting  at  Quadrant  I  (9:00),  the  objectives  and  constraints  of  the  spiral  suge  are  determined.  In 
Quad.-ant  Q.  spiral  nsk  analysis  and  risk  mitigauon  are  accomplished.  Principle  activities  are  analyses  and 
assessments  as  well  as  prototypes  and  simulations  depending  on  the  particular  spiral  stage  and  objectives.  In 
Quadrant  III  the  spiral  products  are  developed.  In  Quadrant  IV,  ihe  project  spiral  planning  and  management  aciiviiics 
are  conducted.  Transitioning  enteru  suppon  evaluations  before  a  decision  is  made  to  advance  to  the  next  major 
spiral.  There  is  no  intended  implicauon  of  elapsed  time  wuhin  a  spual.  Some  spirals  may  be  of  long  durauon 
while  others  may  rcprujim  a  very  rapid  sei  of  activities  and  products.  In  addibon.  there  may  be  subspirals  wiihin  a 
spiral  to  address  specific  nsks,  and  spirals  may  overlap  within  a  project  life-cycle.  A  true  conceptual  viev’  of  the 
spiral  process  will  depend  on  an  actual  project  realizaaon. 
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Key  Elements  of  the  Composite  Process  Model 

•  Risk  i.lanagement  •  Engineering  for  Trust,  Performance  and  Reuse 

•  Ada  •  Control  and  Assurance 


Using  ihe  TRW  DARPA  ACS  process  model  as  a  technical  foundation, ws  developed  the  reuse  based  acuviiies  with 
t*o  pr.mary  sraegies.  First,  the  Composite  Process  Model  stresses  the  early  identification  of  risks  (a  characierisiic 
of  its  spiral  foundation)  and  organizes  subsequent  development  activities  to  miugate  them.  Second,  the  Composite 
Process  Model  calls  for  the  integration  of  reuse,  trust  and  performance  engineering  with  modem  software  practices. 
The  figure  shows  the  motivations,  drivers  and  key  elements  of  the  resulbng  model.  Reuse-based  drivers  and 
coa'Taints  are  highlighted.  The  domain  of  a  specific  application  will  constrain  the  adaptation  of  the  Composite 
Process  .Model.  The  spual  insen  illustrates  the  conceptual  base  for  four  generic  quadrant  classes  of  each  cycle  and 
the  segments  of  activities  within  each  quadrant  Wc  will  lock  more  closely  at  concepiualizabons  of  spiral  acuviues 
later  in  this  briefing.  The  model  key  elements  may  include,  for  example,  1)  Risk  Management;  fonnal  risk 
methodologies,  modeling,  plxming  for  reuse,  proiotyping  and  demonstratiTns,  analysis  of  'cuse  candidates  and 
incremental  development;  2)  Enginccr.ng  for  Trust.  Performance  and  Reuse;  architecture  assessment  (model, 
prototype),  criucal  mechanism  prototyping  and  iniegrauon  of  cnucal,  reusable  assets;  3)  Ada:  h.rfnoge,neous 
represemaiion.  consistent  metrics  and  language  suppon  for  reuse;  4)  Control  an''  Assuance;  reaso.iing-hasoc 
analysisiassurance,  reuse  of  assurance  results,  CM  and  control,  control/managemeni  of  reuse  library. 
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ASSUMPTIONS,  WHAT  IT  IS/ISN’T 


Composite  Process  Model  Assumptions 

•  Domain  Well-Defined 

•  Early  Domain  Analysis  and  Planning  Done 

•  Top  Level  Reuse  Requirements  Established 

•  Reuse  Infrastructure  Exists 

Composite  Process  Model  Is 

One  Example  of  Reuse  in  a  Life-Cycle  Model 

•  liitorial  Description  of  Composite  Process 

•  Not  a  Detailed  Prescription 

•  Not  Domain-Specific 

•  To  be  Interpreted  for  Application 


The  Gjmposite  Process  Model  describes  domain-indepcndeni,  top  level  project  activities  that  must  necessarily  follow  | 
project  conceptualization,  planning  and  an  already  established  initial  approach.  There  are  fundamental  assumptions 
about  the  state  of  reuse  prior  lo  the  first  spiral  of  activities.  These  assumptions  are:  the  domain  of 
interesi/appii04aon  is  well-defined;  early  domain  analysis  and  planning  are  already  accomplished,  top  level  reuse 
requiremerts  (goals  for  project  use,  management  and  creation  of  reusable  assets)  ane  established  and  a  reuse 
in^mic  aire  Gibrary  of  assets,  engineering  cn-vironment,  methodology  and  tools)  exists.  The  Composite  Process 
Model  is  an  interim  step  toward  a  domain-specific  process  model.  As  previously  mentioned,  we  initial'y  modeled 
the  process  for  domain  analysis  and  precontract  activities  in  the  Navy  Command  and  (Control  (C^)  domain  with  a 
Spiral  0  followed  by  the  five  spirals  identified  in  the  composite  process,  tailored  to  the  application  domain.  The 
Composite  Process  .Mi.idel  is  one  example  of  reuse  in  a  complete  project  life-cycle  model.  Because  of  its  vast  scope 
and  its  top  level  objecuves,  it  is  not  a  detailed  prescription,  rather  it  is  a  tutorial  description  of  the  composite  process 
that  incorporates  reuse  and  traditional  project  acuvities  into  a  risk -driven  process  model.  As  mentioned,  the 
Composite  Process  Model  is  not  domain-specific,  it  must  be  tailored  to  a  specific  domain.  Importantly,  ihe  model 
must  be  interpreted  for  application  to  any  real  world  project;  and  prescriptive  guidance  with  specific  activities, 
development  environment  characteristics  and  management  controls  must  be  defined. 
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0\T.R\TEW  OF  THE  PROCESS  MODEL 

Spiral  0:  (Domain- Specific)  May  Define  Domain  Analysis  and  Relevant 

Early  Activities 

Spiral  lx  Initial  Project  Plans  and  Analysis  of  Reuse,  Trust  and 

Performance  Requirements 

•  Example  Reuse  Activities 

-  Identify  Reuse  Policy 

-  Assess  Reusable  Assets 

-  Assess  SEE  Capabilities 

-  Document  Reuse  Requirements 

-  Incorporate  Reuse  mto  Life-Cycle  Plan 

-  Identify  Reuse  Risks 

The  next  !ivfi  viC'A'^ranh^  rrr^^nt .u^.  I,...,,  .u- 1  j _ 

Lmpmamt  Xmt  0»it^mlV(77 

,  *  J  yvcrvicw  mai  lisLs  wc  iniuai  aomajn-bascd  process  Soira)  0  and 

S^?,'t?Sp model.  Pnncple  muse-based  acuv,u«  are  Usfed  for  uw 

If  hioh  TiT^n  rcptesenimg  the  five  major  groups  of  acuvitics  in  the  development 

LS-ffsTuSXr'^h  ProcS  Model  report,  and  a  list  of  ^ 

n  ^  addJuon,  a  conceptual  view  of  each  spiral  is  iilustrated  with  major  activiPes 

fc  iTi  H  ^  Rcus^vines  are  integrated  into  each  quadrant  and  spiral  ImpliciUy  and^xpbciUy  reuse 

°f  ^t^viues  i^ntlun  eih  quadrat  stem  tom  ^te^me 
anem^.5  over  sc\e^  cy-cles  to  reduce  the  crucial  technical  and  program  risks  in  reuse-dnven  develo^menu  and  in 
systems  requuwg  high  trust  and  perfcrmance.  Assuming  a  domain-specific  basis,  the  Composite  Process  Model 
incorporates  the  considerations  for  reuse  activities  within  the  quadrant  segments  for  ■ 

Spiral  1  ^lual  Proj^t  Plans  and  Analysis  of  Reuse.  Trust  and  Performance  Requirements 

ipiral  .  Reuse  nd  Trust  Enforcement  Strategy  and  Basic  Architecuire 

Spiral  j  Cnucal  Elements  and  Architecture  Refinement 

Spual  4  System  Development  and  Assurance 

Spiral  5  .Mamicnance. 

f  f  T  ^  Spiral  0.  -Rie  aciual  rtprescmauon  of  spiral,  and  ihc 

nu.m...  cf  spirals  may  vary  c;epend..n5  on  a  specific  project  s  need.  For  example.  Spirals  1  xnd  could  be 

r.xn.,^a^„aJ  ■»  may  rM.^.re  pamjor.mg  mio  multiple  spirals  on  a  more  complex  projecu  E-xample  reuse  .r-cvii-M 
.,:c.  represent  a  subset  o  the  full  list  of  acu.ities  for  Spuals  I  through  5  L  pS'med  hei^o  .n.ruJte  sSme  S 

-f  'h  “■  °  draught  of  as  a  subprocess  to  be  modeled  for  a  paracular 

pro^ieci  Within  a  de.fined  application  domain.  ui  a  i-u ac mar 
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This  figure  illusuaies  a  conceptual  view  of  Spiral  3.  Cnucal  Elements  and  Architecture  Refinement  of  the 
Composite  Process  Model.  It  also  shows  an  Assessment  Sector  that  overlaps  a  number  of  spirals.  In  the  sector 
stanmg  in  Quadrant  1.  we  can  see  the  Spiral  1  (and  2)  acuviues  that  lead  to  project  objectives  and  nsk  mitigation 
include  miual  assessments  for  reuse,  proposed  COTS  products,  the  software  engineering  environment  and  an 
assessment  of  project  reuse  (and  other)  risks.  Spirals  1  and  2  include  analyses  of  reuse  capabilities.  If  we  follow  the 
Spiral  3  acuvibes  starring  in  Quadrant  1  (Objectivr.s).  we  trace  the  definition  of  spiral  objectives  and  expenmentauon 
with  cnucal  project  elements.  These  elements  are  essenbai  for  projea  success  and  may  represent  such  things  as 
high-risk  reuse  asset  ubUzation,  trust  mechanisms,  high  performance  elements,  or  user  interface  functions.  Spiral  3 
Quachant  n  (Risk  Analysit)  acuviues  illusuate  risk  mtugauon  that  includes  an  assessment  of  the  application  of  die 
process  model  to  date,  ani'lyses  of  reuse  prototypes  and  the  qualificar.oTS  of  reusable  asseu.  assessments  of  cntical 
components,  pcrfonnance  assessments  (as  reievam).  revised  risk  assessments,  trust/reuse/cnaca]  function  prototypes 
as  applicable  and  trust  modeling  as  needed.  The  Prouxype  and  Modeling  Sector  may  also  be  conceptualize  as  being 
pan  of  Quadrant  m  (Developmem)  since  projeci  products  may  result  from  those  acuviues.  Development  products 
may  include  design  documentaaon.  system  architecture  dexnpbons  and  assurance  evaluaoon  evidence.  Quadrant  fV 
represents  project  planning,  plan  revisions  and  evaluation  of  current  progress  before  the  transiiion  lo  Spiral  4  can 
occur. 
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LNTEGRATING  REUSE 

DOMAIN  TAILORING  EXAMPLE 

•  Initiated  Domain  Tailoring  of  Composite  Process  Model 

-  Risk-Reduction,  Reasoning-based  Development  Paradigm  Tailored  to 

Navy  C‘  Systems 

•  Integrated  the  Following:  ^ 

-  Composite  Process  Model 

-  Prelimiaar>  Navy  Command  and  Control  Domain  ^knalysis 

-  Definition  of  Pre-contract  activities 

-  Domain  Risks  applied  to  Spiral  Process 

-  Determination  of  Government- Specific  Activities  (as  well  as 

contractor  activities) 

Under  STARS  tasking,  we  conducted  an  initial  domain  analysis  and  identified  a  preliminary  set  of  domain  nsks  and 
charactenstics  for  Navy  System  develoomeni.  The  Composite  Process  model  was  adapted  to  the  Navy  C- 
domain,  and  the  resulting  Navy  Process  Model  (NCCP.Nf)  is  documented  in  the  STARS  report.  Risk- Reduction. 
Reasonuig’Based  Development  Paradigm  Tailored  to  Navy  Systemi.  The  preliminary  domain  analysis  work  is 
summarized  in  an  Appendix  A  to  this  report.  The  NCCPM  work  adapts  the  Composite  Process  Model  uj  the 
pteliminaiy  oomain  analysis,  defines  pre-contnci  activities  for  the  Navy  and  other  organizations,  applies  domain 
nsks  to  ea^  spiral  of  acuvicy  and  determines  and  integrates  specific  Government  and  contractor  development 
activities  for  each  spiral 
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INTEGRATING  REUSE 

DOMAIN  TAILORING  EXAMPLE 


•  Developed  Risk  Summary  Tables 

-  Technical  and  Programmatic  Risks 

-  Risk  Mitigation  Activities  Mapped  to  Relevant  Spirals 

•  Defined  Preliminary  Tables  Mapping  Standards  to  Spirals 

•  Created  Spiral  O:  Concept  Through  Contract  Award 

-  Domain  Analysis  Activities 

-  Pre-Contract  Activities  (Sponsoring  and  Performing  Organizations) 

-  Description  of  Domain- Specific  Reuse  Activities 

-  Five  Subspirals 


The  NCCPM  repon  specifies  domain-specifiC  reuse  risks  and  ar''viiies  that  mitigate  those  risks  throughout  the 
process  life-cycle.  These  actiMties  are  summarized  in  risk  ub  that  map  risks  to  spirals  (0-5).  The  Composite 
Process  Modd  tailoring  to  a  specific  domaui  also  includes  initia.  tables  that  map  such  starxlards  as  DoD  2167A  and 
DoD  5200.25-STD  to  project  spuals.  The  NCCPM  includes  a  Spiral  0  for  domain  analysis  and  precontract  process 
modeling  for  bodi  sponsoring  and  performing  organization  aedvities.  Spiral  0;  Concept  Throi'gh  Contract  Award 
consists  of  five  subspuals  that  list  the  many  early  activities  required  d  define  the  system  concept,  initial 
specifications  and  R^,  preparations  to  respond  to  the  RFP.  and  the  writing  and  evaluation  of  proposals. 


The  Composite  Process  Model  is  one  sample  of  integrating  reuse  into  a  process  model;  one  interim  step  toward  the 
STARS  reuse  goals.  Interpreted  for  a  specific  application  domain,  the  Composite  Process  Model  is  one  approach 
for  STARS  domain-specific,  reuse-based  megapnogramming  support.  The  model  addresses  the  full  life-cycle 
development  process  for  a  nsk-drivcn  system  dcvelcpmem.  It  provides  a  paradigm  for  large  scale  systems  and  for  the 
development  of  high  assurance  (trusted)  systems.  Some  of  the  types  of  developments  that  are  especially  suited  to  the 
paradigm  are  safety  critical  systems  such  as  fUghi  control,  medicine  dispensing  applications,  etc,  and  highly  trusted 
systems  such  as  multilevel  secure  systems.  In  addition,  because  of  its  built-in  flexibiiiiy  and  nsk  mitigation 
emphasis,  the  Compcsiie  Process  Model  is  clearly  appropriate  for  research-based  system  developments.  (e.g„  In 
phase  II  of  the  DA^A  ACS  research  project.  TRW  and  ns  subcontractors  are  applying  the  foundtiicn  process 
model  to  the  develop  mem  of  a  trusted  X  Window  System  prototype  aimed  at  the  B3  level  of  trust)  There  are  future 
tasks  that  would  enhance  the  appLcability  of  the  Composite  Prrx^  Model.  Our  suggestions  to  the  software 
cngincenng  community  are:  1 )  Develop  a  guidebook  for  the  Composite  Process  Model  that  woiild  provide  more 
prescriptive  steps  for  imerpreutior  and  use  of  the  model  for  a  real-world  application;  2)  Tailor  the  Composite 
Process  Model  to  other  example  domains  and  provide  feedback  for  improving  the  cunent  process  as  well  as  more 
explicit  process  model  descriptions  that  are  applicable  for  their  specific  domains;  3)  Validate  the  Composite  Process 
Model  through  actual  project  use;  provide  feedback  for  process  improvement  so  that  the  model  can  evolve  to  a 
viable,  visible  supporang  element  of  the  STARS  reuse  vision. 
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This  presentation  is  a  bncf  inmxJucnon  and  overview  of  the  STARS  Eionuun  Analysis  Process  Model. 

It  is  one  of  the  building  blocks  of  a  model  for  reuse  library  processes  being  developed  for  STARS. 

The  model  for  Reuse  Library  Processes  is  available  in  report  formal  from  STARS.  It  is  cnuiJed  STARS  Reuse  Library 
Process  Model. 
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DOMAIN  ANALYSIS  PROCESS  MODEL 

OUTLINE 


•  Context  for  the  Domain  Analysis  Process  Model 

-  Basic  activities  for  building  libraries 

-  The  domain  analysis  building  block  process 

•  Domain  analysis  concepts 

-  What  is  domain  analysis  (DA) 

-  Why  necessary 

-  An  approach  to  DA 

•  Domain  Analysis  Process 

-  High  level  view 

-  A  peek  into  details 

•  Applications 

-  Naval  Training  Systems  Center  Project  (NTSC) 

-  Other  STARS  activities 

-  Future  work 

Domm  AMiyvt 


The  Domain  Aiulysis  Process  Model  was  developed  as  one  o(  the  subprocesses  for  developing  and  managing  reuse 
Ubranes. 

This  presenianon  describes  briefly  the  activities  of  the  library  process  model  lo  illustraie  the  role  of  domain  analysts  within 
the  context  of  creaung  reuse  libraries. 

Some  basic  concepts.  jusuficaLon.  and  views  of  domain  analysis  will  be  introduced  along  wnih  a  desenpoon  of  the  process. 
The  process  is  summarized  by  listing  die  high  level  acuvmes  involved.  Selected  diagrams  are  also  shown. 

The  presemauon  concludes  with  desenpeon  of  some  of  the  applications  of  the  model  inside  and  outside  STARS. 
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DOMAIN  ANALYSIS  PROCESS  MODEL 

CONTEXT  FOR  DOMAIN  ANALYSIS 

Part  of  a  model  for  reuse  library  processes  developed  for  STARS 

•  Formal  characterization  of  reuse  library  processes 

•  Includes  creation,  operation,  and  management  of  reuse  libraries 

•  Supports  franchise  view  of  distributed  libraries 

•  Focus  is  on  domain  analysis 

•  SADT  format 

0mm  IT.f 

The  objective  of  ihe  Ubrar>'  process  model  is  to  formally  characterize  the  various  processes  that  take  place  in  the  context  of 
Reuse  Ltbtanes. 

These  processes  include  not  only  the  operation  and  management  of  reuse  libraries  but  the  preparation  and  analysis  work 
required  for  establishing  such  libraries  in  panidpating  organizations. 

This  model  supports  a  franchise  view  of  library  developmenu  The  current  version  of  the  library  process  model  concentrates 
on  how  to  create  standard  reuse  libranes  to  facilitate  the  implemeniauon  of  a  nauonwide  reuse  program. 

Standard  guidelines  make  possible  the  development  of  independent  libranes  with  common  requirements  and  at  the  same 
time  provide  certain  degree  of  flexibility  for  organizations  to  specialize  in  specific  application  domains.  This  flexibility 
allows  for  a  quick  and  decenoraitzed  development  of  sDeciaiized  libranes  resulung  in  a  rapid  expansion  of  the  reuse  library 
base. 

The  Domiin  Analysis  componeni  plays  a  key  ole  tn  .creating  domain  specific  libranes  that  suppon  a  reuse-based  software 
development  The  model  ts  decompcscd  to  ■very  low  detail. 

TTie  orescntauon  format  is  SADT.  a  trademark  of  SofTcch.  SADT  is  a  technique  for  thinking  in  a  structured  way  about 
large  and  complex  probiemi  and  includes  a  graphical  notaaon  that  is  clear  and  precise  in  communicating  system 
funcuorulity. 
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DOMAIN  ANALYSIS  PROCESS  MODEL 

TOP  LEVEL  ACTIVITIES 


AO  -  Develop  reuse  libraries 

A1  -  Assess  organization  capabiliti<‘s  for  developing  a  reuse  library 

.A2  -  Define  reuse  program  plan 

.43  -  .4ssess  reuse  potential  for  domain  of  interest 

■44  -  Create  r‘^use  library  infrastructure 

.45  -  4nalyze  domain 

A6  -  Customize  generic  .4sset  Management  Sy  :tem 

BO  -  Manage  reuse  libraries 
B1  -  Populate  library 
B2  -  Supply  and  filter  assets 
B3  -  Input  assets 

B4  -  Operate  and  maintain  library 

B5  -  Maintain.''verify  catalog  and  classification  scheme 

B6  -  Generate  usage  reports  for  feedback  and  evaluation 

Domb  AMi*ia 


Libran  acuviucs  are  divided  m  wo  nu-n  jroups:  librarv  developmem  and  librar>  management. 

Library  development  includes  assessing  an  organization's  capability  to  dtv.  lop  and  maintain  a  reuse  library .  defining  a 
reuse  plan  tailored  to  the  organizauon's  needs,  assessing  the  reuse  pctenual  for  the  applic^i’or.  duir.vin  where  the  library  is 
going  to  be  used,  the  analysis  of  the  domain,  and  laii'^ring  a  genenc  bbrary  system  to  support  system  c  rmstrucuon  based  on 
domain  specific  architectures. 

Library  .nanagement  includes  the  iruuaJ  r/TpoLiiion  of  the  library,  supply  of  quality  assets,  caiaioging  and  classifying  new 
assets,  horary  operaLion  and  maintenance,  rraintcnance  and  verification  of  catalog  and  cLassificaoon  scheme,  and  report 
generation  and  ev  aluauon. 

To  date  only  the  domain  analysis  process  has  been  developed  moroughly  and  to  a  very  low  level  of  detail.  Although  the 
remaining  acuviues  are  only  desenbed  ui  general,  the  library  model  provides  a  complete  framework  for  the  overall  process. 
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This  is  ihe  usp  level  diagram  for  developing  reuse  libraries.  Inputs  are  decomposed  into  their  more  specific  components. 
The  Organization  Information  input,  for  example,  consists  of  financial  information,  performance  history,  budget,  etc. 
Mechanisms  are  also  decomposed  but  their  classification  is  indicated  by  a  number  (bottom  left  in  the  diagram). 
Mechanisms  of  class  (1)  are  from  the  client  organization,  class  (2)  are  reuse  library  specialists,  and  class  (3)  are 
commissioned  staff  fiom  the  STARS  program.  Intermediate  outputs  are  named  in  the  diagram  and  their  association  with 
respective  arrows  is  indicated,  in  most  cases,  with  a  line  and  a  small  circle.  The  rightmost  outputs  are  aggregations  of 
intermediate  ouq^uts. 

There  are  several  intermediate  ouqjuis  that  are  used  as  controls  or  inputs  to  other  activities.  The  implementation  plan 
created  in  A2,  for  example,  is  used  to  guide  {i.e.,  control)  the  creation  of  the  reuse  infrastructure  A4. 
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DOMAIN  ANALYSIS  PROCESS  MODEL 

DOMAIN  ANALYSIS  CONCEPTS 


•  Domain  analysis  is  a  key  technology  for  implementation  of 
domain-specific  reuse-based  software  development 

•  mat  is  DA? 

-  Neighbors;  'T/te  activity  of  identifying  objects  and  operations  of  a 
class  of  similar  systems  in  a  particular  problem  domain.**  [1980] 

-  Simplified  View;  *’DA  is  systems  analysis  for  a  class  of  systems 
rather  than  for  a  single  system.**  [PD] 

-  General  View;  '*DA  is  the  process  by  which  information  used  in 
developing  SfW  systems  is  identified,  captured,  and  organized  with  the 
purpose  of  making  it  reusable.**  [PD] 

•  Process  based  on  a  methodology  for  deriving  specialized  classification 
schemes 

«  Exploits  iteration  concept:  identification,  selection,  abstraction,  and 
classification  cycle  OrniM  *mtrm  tnam  OimW;* 


Domain  analysis  holds  die  key  to  a  systematic,  formal  and  effective  practice  of  software  reuse.  To  be  effective,  reusable 
assets  must  integrate  easily  within  a  predefined,  and  preferably,  standard  architecture.  The  task  in  domain  analysis  is  to 
develop  such  an  archiiecuire  and  provide  the  information  needed  to  ^lecify  standard  comptmenis. 

Most  proposed  approaches  and  methods  for  domain  analysis  assume  that  domain  knowledge  exists  and  is  readily  available 
and  usable.  Experience  indicates  however,  that  acquiring  and  structuring  knowledge  is  a  bottleneck  of  domain  analysis. 

The  current  model  is  based  on  an  earlier  model  proposed  m  1987  based  on  a  method  for  deriving  fveted  classification 
schemes  for  special  collections. 

The  key  concept  is  an  iterative  loop  of  idenhlicauoo,  selection,  abstraction,  and  classification  of  domain  information. 

This  loop  can  be  represented  as  a  spiral 
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The  spiral  starts  with  identificaiion  of  specific  objects,  operations,  and  relationships  ai  a  high  level  of  abstraction. 

Relevant  objects  and  operations  are  selected  and  then  abstracted  to  capture  their  essential  attributes/charactensdes  or 
features. 

The  objects  and  operations  are  then  classified  by  their  common  attributes. 

As  the  spiral  progresses,  structures  are  integrated  into  larger  elements  of  the  archiiecuire. 

This  basic  process  is  similar  to  a  process  practiced  in  libtary  science  to  derive  classification  schemed  called  literary 
warrant. 

The  new  approach  complements  this  bouom-up  approach  with  a  top-down  preliminary  identificatjon  of  generic 
architeenrres. 
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DOMAIN  ANALYSIS  PROCESS  MODEL 

SUMMARY  OF  THE  DA  APPROACH 


•  Select  domain  ^th  highest  reuse  potential 

-  Look  at  current  projects:  scope  and  define  domain 

-  Evaluate  current'future  needs,  current  practice,  feasibility 
Define  purpose 

•  Top-down  analysis 

-  Identify  high  level  architecture  and  functional  model 

-  Select  functional  components  with  high  reuse  potential 

-  Re-define  architecture  (with  reuse  in  mind) 


•  Bottom-up  analysis 

-  Vocabulary  analysis 

-  Classification  model 

-  Functional  clustering 

•  Derive  generic  architecture 

-  Map  bottom-up  functions  into  architecture 

-  Adapt  architecture 

-  Derive  other  models 


OnM  irnlTM  itotd/Tw—  l>ittVC« 


This  is  a  summary  of  the  proposed  domain  analysis  process. 

The  activities  in  the  dotted  box  can  be  considaed  as  preparation  for  domain  analysis.  The  objective  is  to  assess  the  reuse 
potential  of  a  selected  domain  and  to  define  the  purpose  of  the  analysis.  The  purpose  of  a  domain  analysis  may  range  from 
providing  a  basic  understanding  of  the  domain  to  developing  a  common  architecture  itcluding  specTicaoons  for  reusable 
building  blocks. 

The  process  follows  a  sandwich  approach.  It  is  based  on  a  combination  bouom-up  and  top-down  approach  similar  to  the 
one  used  in  developing  software  systems.  During  the  bouot.i-up  stage,  low  level  requirements,  source  code,  and 
documentation  from  existing  systems  are  analyzed  to  produa^  a  preliminary  vocabulary,  a  taxonomy,  a  classification 
structure,  and  standard  descriptors.  During  the  top-down  stage,  high  level  designs  and  requirements  of  current  and  new 
systems  are  analyzed  for  corrunonality.  The  outcome  of  this  analysis  includes  a  canonical  structure  common  to  all  systems 
in  the  domain,  identification  of  stable  and  variable  characteristics,  a  generic  functional  model,  and  information  on  the 
interrelationships  among  the  structure  elements. 

The  outcomes  of  both  approaches  are  integrated  into  reusable  structures.  This  integration  process  consists  of  associating  the 
products  of  the  botiom-up  analysis  with  the  structures  derived  by  the  ajp-down  analysis.  The  result  is  a  nauiral  match 
between  high  level  generic  models  and  low  level  components.  Assembly  of  new  systems  from  basic  components,  thus, 
becomes  a  library  search  and  retrieval  operation  using  the  domain  models  as  skeleton  guides. 
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DOMAIN  ANALYSIS  PROCESS  MODEL 

DOMAIN  ANALYSIS  PROCESS 


AS;  AMlyzt  Domain  riMin  DiM/ve* 


Tlus  (Uagram  represtnis  the  high  level  decomposiuon  of  the  domain  analysis  process.  The  four  activities  arc  highly 
inierrelaied.  The  first  activity.  "Prepare  Domain  Infoimaiion"  includes  a  preliminary  top-down  analysis  to  propose  a  basic 
"descriptive"  architecture.  The  next  two  activities,  "Classify  Domain  Entities"  and  "Derive  Domain  Models"  are  the  core  of 
the  bottom-up  analysis.  In  the  last  activity,  "Expand  and  Verify  Models  and  Classification”,  the  preliminary  high  level 
architecture  is  revised  and  modified  to  include  the  domain  models.  After  some  iterations,  a  "prescriptive”  architecture  made 
of  reusable  structures  is  generated. 

The  diagram  shows  the  inputs  for  each  activity,  the  intermediate  outputs,  the  feed-back  loops,  their  respective  controls  and 
mechanisms,  and  the  final  outputs. 

It  is  decomposed  into  several  subactivities,  each  described  in  detail  and  with  examples. 
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DOMAIN  ANALYSIS  PROCESS  MODEL 

PREPARE  DOMAIN  INFORMATION 


AMknm  Pnmm  0>iA‘Cl0 


This  diagram  is  an  example  of  a  third  level  decomposidoa 

It  shows  the  activioes  involved  in  preparing  domain  infonnation  and  the  outputs  expected. 

The  outputs  are  mainly  in  the  form  of  reports. 

Lower  level  decompositions  produce  specific,  well  defuied  outputs. 

Decomposition  is  carried  to  level  five. 

Many  of  the  lowest  level  activities  could  be  automated  and  mon  of  them  with  current  technology. 
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DOMAIN  ANALYSIS  PROCESS  MODEL 

APPLICATIONS 


•  Naval  Training  Systems  Center  (NTSC)  reuse  initiative 

-  Domain  analysis  of  four  simulators  (V-22,  UH-1,  P-3A/B,  C-17A) 

-  Produced  domain  models  of  common  subsystems  that  support 
creation  of  reusable  software  objects 

-  Produced  domain  vocabulary  for  the  NTSC  Reuse  Library 

•  Other  STARS  projects 

-  Being  used  as  one  of  the  building  blocks  for  the  STARS  CONORS 
document 

-  Being  adapted  to  support  ASSET  proc.^ses 

-  Being  integrated  into  the  SCPM 

•  Future  work 

->  Assess  feasibility  of  automation 

-  Extend  and  refine  to  include  domain  engineering  activities 

Dbub  Aaahw  r«ai>  Mo<d/?na>-{WVCtl 


The  STARS  Domain  Analysis  Process  Model  has  been  used  in  ihe  tlighv  simulaiion  domain.  The  Naval  Training  Ceniei 
(NTSQ  Reuse  Initiaiive  project  used  it  to  do  a  domain  analysis  of  four  flight  simulators,  the  V-22  Operational  Flight 
Trainer,  the  UH-1  Flight  Simulator,  the  P-3A/B  Tactical  Navigation  Modernization  Operational  Flight  Trainer,  and  the 
C-17A  Weapons  System  Trainer.  The  objective  of  this  domain  analysis  was  to  produce  a  set  of  domain  models  which  will 
support  the  creatioa  and  reuse  of  software  objects  for  the  NTSC  Reuse  Library.  This  in  turn  supports  reuse-based  software 
development 

The  model  is  also  being  used  as  the  basis  for  the  "Create  Assets"  process  in  the  STARS  CONOPS  document  it  is  bemg 
modined  to  support  ASSET  domain  analysis  aedvides  within  their  reuse  library  processes,  and  it  is  being  integrated  into  the 
STARS  Composite  Process  Model. 

Future  work  include  analysis  and  assessment  of  primidve  activides  for  possible  automadon  and  integration  into  a  software 
development  environment  and  extension  to  iitclude  some  domain  engineering  aedvides  dealing  with  asset  aeadon. 
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DOMAIN  ANALYSIS  PROCESS  MODEL 

SUMMARY 


•  The  Domain  Analysis  Process  Model  was  developed  as  one  of  the 
building  blocks  for  a  process  for  establishing  reuse  libraries 

•  Domain  analysis  concepts 

•  High  level  view  and  some  details  of  the  model 

•  Listed  example  of  a  specific  application  and  use  in  other  STARS 
activities 


AMlyM*  fmmn  MarttVrnM-Diw/VCn 


This  presentation  is  about  the  Asset  Libnuy  Open  Architecture  Framework,  known  as  the  ALOAF,  that  is  being 
developed  under  STARS.  The  ALOAF  is  a  set  of  interfaces  that  is  being  defined  to  faciliute  interoperability 
between  heterogeneous  asset  libraries  and  portability  of  tools  across  different  asset  library  mechanisms. 
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ALOAF 

OUTLINE 


•  Motivation 

•  Objectives  and  Approach 

•  Basic  Principles 

•  ALOAF  Specifications 

•  Status  and  Plans 

•  Call  for  Feedback 

This  talk  will  fim  discuss  why  STARS  believes  an  Asset  Ubiaiy  Open  Architecture  Framework  is  needed.  I',  will 
then  focus  on  the  spediic  objectives  of  the  ALOAF  effort  and  describe  the  approach  that  is  being  taken.  Some 
technical  background  information  and  some  of  the  basic  principles  undertying  the  ALOAF  will  then  be  discussed, 
followed  by  a  description  of  the  ALOAF  spedficatiorss  defined  to  date,  in  significant  detail.  Next,  the  current  status 
of  the  ALOAF  effort  and  the  plans  for  19^  will  be  presented.  In  closing  there  will  be  a  call  for  participation  and 
feedback  from  STARS  affiliates  and  the  STARS  community  as  a  whole. 


ALOAF 

THE  NEED  FOR  AN  ASSET  LIBRARY  OPEN 
ARCHITECTIJRE  FRAiVIEWORK 


-DASEA 


•  The  Megaprogramming  Paradigm  Will  be  Facilitated  by  Ready 
Access  to  a  Large  Base  of  Reusable  Assets  Stored  La  Asset  Libraries 

•  The  Number  of  Asset  Libraries  is  Increasing  ...  So  is  Their 
Heterogeneity 

-  Different  Tools 

-  Different  Data  Models 

-  Different  Platforms 

•  Library  Heterogeneity  is  Desirable 

-  Reuse  Library  Technology  and  Processes  Still  Immature 

-  Domain  Specificity  =  >  Diversity 

•  Thus,  Mechanisms  are  Needed  to  Enable  Heterogeneous  Asset 
Libraries  and  Supporting  Tools  to  Interoperate  Effectively 


ALOnriOwnvj 


The  megaprogramming  paradigm  that  STARS  is  addressing  focuses  strongly  on  the  developtnent  of  s^ats  through 
the  reuse  of  existing  assets.  This  paradigm  will  be  facilitated  if  software  engineeis  have  ready  access  to  a  large  base 
of  reusable  assets  stored  in  asset  libraries. 

Fortunately,  the  number  of  asset  libraries  capable  of  supporting  megaprogramming  is  increasing.  However,  those 
libraries  are  proving  to  be  quite  heterogeneous  for  a  variety  of  reasons,  such  as  their  use  of  different  asset  libraiy 
mechanisms  and  tools,  their  dependency  on  different  underlying  hardware  and  operating  systems,  and  their  use  of 
different  dau  models  (and  even  different  styles  of  data  models)  to  describe  the  assets  they  contain. 

This  degree  of  library  heterogeneity  is  not  necessarily  bad,  and  is  aaually  desirable  at  the  present  time.  One  of  the 
chief  reasons  for  this  is  that  reuse  library  technology  and  associated  reuse-related  processes  are  still  highly  immature, 
and  it  is  important  at  this  time  to  condua  additional  experimentation  to  assess  the  technoios'  and  acquire  lessons 
learned  before  standardizing  on  some  small  number  of  specific  approaches.  Furthermore,  one  of  the  key  trends  in 
reuse  libraries  today  is  to  emphasize  a  focused,  domain-specific  approach.  This  approach  will  necessarily  promote 
heterogeneity  because  the  specific  libiary  dau  models  for  different  domains  will  naturally  be  quite  diverse.  In 
addition,  it  is  important  at  this  suge  in  the  development  of  reuse  technology  to  promote  competition  among 
technology  development  efforts  to  motivate  needed  advancements. 

Considering  that  library  heterogeneity  is  here  to  suy  for  the  foreseeable  future,  it  is  clear  that  mechanisms  are 
needed  to  enable  the  growing  population  of  heterogeneous  asset  Ubraries  and  their  supporting  tools  to  interoperate 
effectively  to  satisfy  megaprogrammer  needs. 
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ALOAF 

OBJECTIVES 


•  Define  a  General  Library  Model  Articulating  Fundamental  Arset 
Library  Concepts 

•  Define  Interfaces  to  Enable  Heterogeneous  Libraries  to  Interchange 
and  Share  Assets 

•  Define  Interfaces  to  Enable  Seamless  User  Access  to  Muliiule 
Libraries  Through  a  Set  of  Portable,  Interoperating  Reuse  lools 

•  Foster  Establishment  of  Standards  for  Libraiy  Interoperability 


ALOAflOfptVCM 


Four  speaflc  ALOAF  objectives  have  been  defined  to  address  the  identified  needs. 

First  of  all,  we  felt  it  necessary  to  define  a  general,  conceptual  model  of  an  asset  library,  to  help  us  articulate 
fundamental  library  concepts  and  properly  define  and  scope  ALOAF  capabilities. 

Secondly,  we  wish  to  define  a  set  of  interfaces  to  enable  libraries  to  interchange  asset  desci^tions  and  asset  contents, 
and  possibly  to  share  single  copies  of  asset  data  where  appropriate. 

In  addition,  we  are  striving  to  define  a  set  of  programmatic  interfaces  to  enable  seamless  user  access  to  a  variety  of 
asset  libraries  through  a  set  of  interoperating  reose  tools  that  are  portable  across  difierent  asset  library  mechanisms. 

Finally,  since  one  of  the  key  objectives  of  the  STARS  program  as  a  whole  is  to  promote  development  and  adoption  of 
software  engmeering  standards,  ]>erfaaps  the  most  important  ALOAF  ol^ectrve  is  to  foster  establishment  of  widely 
accepted  standards  for  library  interoperability. 
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ALOAF 

DEVELOPMENT  APPROACH 


•  Jointly  Developed  by  STARS  Prime  Contractor  Teams 

•  Primary  Initial  Focus  on  STARS  Asset  Librai7  Needs 

•  Validated  Concurrently  by  Primes  Through  Iterative 
Implementation,  Experimentation,  Feedback 

•  Scope  Being  Extended  Beyond  STARS  Library  Mechanism:^  by: 

-  Working  with  Related  Standardization  Efforts 

-  Iniluencing  Them  Where  Appropriate 

-  Incorporating  Relevant  Evolving  Standards  into  ALOAF 


ALPATfOm/yCS 


This  slide  describes  the  overall  approach  that  STARS  is  taking  to  develop  the  ALOAF. 

The  ALOAF  is  being  jointly  developed  by  representatives  from  each  of  the  STARS  prime  contractor  teams  and 
MITRE  CotporatioD.  This  joint  aptproach  will  ensure  that  a  broad  spectrum  of  views  is  reflected  in  the  document 
and  that  the  needs  of  all  the  primes  are  adequately  addressed.  As  this  implies,  the  initial  focus  of  the  ALOAF  effon 
has  been  on  STARS’  perceived  asset  library  needs. 

A  key  element  of  the  approach  is  that  the  STARS  contractors,  who  are  also  tasked  to  develop  and  integrate  asset 
library  mechanisms,  are  an  ideal  testbed  for  the  ALOAF  results.  The  ALOAF  will  thus  be  validated  ly  the  primes, 
oottcurrent  with  ALOAF  development  and  evolution,  through  an  herative  cycle  of  implementing  the  ALOAF 
mechanisms,  operimenting  with  and  assessing  the  mechanisms,  and  providing  feedback  to  the  ALOAF  team  to 
enhance  and  evolve  the  mechanisms. 

However,  in  accord  with  our  objective  to  foster  the  establishment  of  srandards  for  Libiary  interoperability,  we  will 
also  strive  to  extend  the  scope  of  the  ALOAF  beyond  just  the  STARS  library  mechanisms.  Our  approach  here  is  to 
work  closely  with  related  standardization  efforts  such  as  tne  Reuse  Library  Interoperability  Group  (RIG),  influence 
those  efforts  where  appropriate,  and  incorporate  the  relevant  emerging  standards  back  into  the  ALOAF. 
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ALOAF 

DEVELOPMENT  STRATEGY 


•  Short-Term; 

-  Focus  on  Asset  Interchange  Between  Libraries,  in  Terms  of  a  Simple 
Common  Data  Model  for  Describing  Assets 

-  Validate  Initial  Asset  Interchange  Through  Experiments  With  STARS 
Asset  Library  Mechanisms 

•  Long-Term; 

-  Focus  on  Seamless  Library/Tool  Interoperability  and  Generalized 
Asset  Interchr''.ge 

-  Define  Extensive  Set  of  Asset  Library  Services 

-  Provided  by  ALOAF-Compliant  Servers 

-  Accessed  Directly  by  Client  Tools  Distributed  Across  a  Network 

-  Establish  Interfaces  for  Generalized  Description  and  Interchange  of 
Library  Data 

Aia»rio^inr)» 


STARS  is  focusing  on  both  a  short-term  and  a  long-term  strategy  for  ALOAF  development  and  validation. 

The  short-term  strategy,  designed  to  take  advantage  of  existing  technology  and  provide  a  basic  libraxy  interoperability 
capability  that  can  be  employed  now.  focuses  on  the  interchange  of  assets  between  libraries.  This  interchange  is 
fadliuted  a  Common  Data  Model  for  desoibing  the  general  charaaexistics  of  assets  in  a  common  form.  An 
initial  experiment  is  currently  under  ws^r  to  assess  and  validate  this  approach  by  using  the  SIARS  asset  libTar> 
mechanisms,  and  additional  such  e3q>eriments  will  be  undertaken  as  the  ALOAF  evolves. 

The  long-term  strategy  focuses  on  the  notion  of  “seamless”  interoperability  of  libraries  and  their  supporting  to^;S,  as 
well  as  on  generalizing  the  asset  interchange  capabilities.  In  a  seamless  environment,  the  library  user  will  have 
network  access  to  a  variety  of  libraries  that  all  appear  to  be  relatively  homogeneous,  with  the  probable  eseption  ?f 
their  data  models.  This  will  be  e&eaed  by  defining  a  set  of  standard  asset  library  services  accessiUe  from 
ALOAF-compliant  servers  by  dient  tools  distriboted  across  a  network,  via  some  form  of  client-server  protocol. 
Libraries  will  continue  to  interoperate  via  asset  interchange,  as  well,  but  the  inteidiange  capabilities  will  be 
generalized  to  enable  libraries  to  interchange  a  much  richer  set  of  information  than  can  be  represented  by  the 
Common  Data  Model. 
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This  figure  may  help  oystaUize  the  ideas  diseased  in  the  preceding  slide.  We  see  here  a  somewhat  jfntuxistic  view  in 
which  there  are  numerous  asset  libtaries  all  interconnected  via  the  Internet  Many  of  them,  such  as  CARDS, 
RAPED,  RAASP,and  so  on,  are  libraries  focusing  on  specific  application  domains,  while  other  libraries,  such  as 
ASSEX  provide  access  to  components  with  more  general  applicability.  Some  of  the  libraries,  such  as  ASSET  as 
depicted  here,  may  provide  ‘bellow  Pages”  services  to  refer  (or  possibly  directly  connect)  users  to  libraries  containing 
specific  assets  or  classes  of  assets. 

Within  this  distributed  library  context  there  are,  in  the  shaded  area,  a  coiiection  of  client  tools  providing  distinct 
user  interfaces,  such  as  those  provided  by  ROAMS,  RLF,  AMS,  and  so  on.  This  is  meant  to  indicate  that  a  user  at 
any  particnlar  site  could  choose  whichever  user  interface  is  most  suitable  and  be  able  to  access  each  of  the  libraries 
with  ALOAF-compliant  servers  through  that  user  interface  in  a  natural  maimer.  However,  even  in  a  futuristic 
scenario,  not  all  libraries  will  be  expected  to  have  ALOAF-compliant  servers,  but  these  libraries  will  still  be  able  to 
interoperate  with  other  libraries  via  asset  interchange. 
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ALOAF 

ASSET  LIBRARY  MODEL 


m 


AsMt  Ubnry  Mechansm 


UDfary  Tools 


AssscUbwy  .P\>^ 
frvrmioifi 
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Tbis  figure  is  a  high-level  conceptual  view  of  the  general  asset  libraiy  model  we  have  defined.  In  this  view,  an  Asset 
library  consists  of  two  major  components:  the  Asset  Libraiy  Mechanism  that  provides  the  general  fimctioDality  of 
the  libraiy,  and  the  Asset  Libraiy  Data  that  indndes  both  desorptions  of  the  libiaiy  contents  as  well  as  the  comenu 
themselves. 

The  AsKt  Libraiy  Mechanism  contains  an  Asset  Libraiy  Framework  that  provides  Framework  Services  to  a  set  of 
Libraiy  Tools  through  which  a  variety  of  library  users  (e.g^  asset  renseis,  library  administrators,  asset  ceitifieis) 
interaa  with  the  libiaiy.  The  Asset  Libraiy  Mechanism  encapsulates  an  implicit  meu-data  model  which  is  realized 
through  the  Framework  Services  to  enable  the  definition  cf  a  Libraiy  Data  Model  The  Libraiy  Data  Model  defines 
the  structure  oi  the  Asset  Descriptions  that  describe  individual  assets.  The  Library  Data  Model  and  the  Asset 
Descriptions  together  are  refened  to  as  the  Asset  Catalog.  The  Asset  Descriptions  point  to  the  files  or  objecu  in 
the  underlying  SEE  that  constitote  the  actual  Assets. 

The  shaded  area  in  the  middle  of  the  figure  indicates  the  area  of  ALOAF  focus.  The  ALOAf  is  focusing  on  defining 
Framework  Services  to  enable  the  definition,  manipulation,  and  interdiange  of  L&iaiy  Data  Models  and  Asset 
Descriptions.  The  Asseu  (Le.,  the  oontenu)  are  considered  to  be  outside  the  scope  of  the  ALOAF  because  they  are 
best  managed  and  accessed  using  undeihying  SEE  services. 
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ALOAF 

ALOAF  SPECmCATIONS  (1) 


•  Meta-Data  Model 

-  Provides  Common  Structural  Mechanisms  for  Defining  and 
Accessing  Asset  Library  Data  iVIodels 

-  Fundamental  to  Asset  Interchange  Specification  and  Service  Model 

•  Asset  Interchange  Specification 

-  Common  Data  Model 

-  Interim  Asset  Interchange  Language  (AIL)  to  Accommodate 
Short-Term  Interchange  Approach 

-  Library-Independent  Representation  for  Library  Data  Models 

-  Library-Independent  Representation  for  Asset  Descriptions 

-  Transfer  Envelope  for  Library  Data  Model,  Asset  Descriptions,  and 
Asset  Contents 


ALotria^t/yB* 


The  next  three  viewgraphs  provide  a  more 


detailed  overview  of  the  ALOAF  specifications  we  are  defining. 


Al  the  core  of  the  specifications  is  a  meta-data  model  which  defines  a  set  of  common  stmcttiral  mechanisms  for 
defining  and  accessing  indtvidnal  asset  library  data  models.  Specifically,  the  meta-model  enables  the  definition  of 
data  models  in  the  form  of  hierarchies,  wherein  each  class  can  be  assigned  attributes  and  particqate  in 
relationshqis,  and  the  attributes  and  relationships  are  inherited  down  the  hierarchy.  The  meta-data  model  is 
fundamental  to  both  the  Asset  Interchange  Specification  and  the  Service  Model  (another  portion  of  the  ALOAF 
specifications,  described  in  a  subsequent  slideX  because  both  of  these  aspects  of  the  ALOAF  rely  heavily  on  a 
common  method  for  describing  and  manipulating  library  data  models. 


The  Asset  Interchange  Specification  will  provide  a  means  for  interchanging  assets  between  libraries  desoibing  the 
assets  and  associated  data  models  using  a  set  of  common  formats.  The  short-term  approach  to  asset  interchange 
required  that  two  things  be  defined: 

o  A  Common  Dau  Model  (CDM)  allowing  assets  to  be  described  in  terms  of  a  set  of  general  asset  diaraaeristics 
that  are  typically  used  to  describe  assets  in  modem  asset  libraries, 
o  An  Asset  Interchange  Language  (AIL)  for  describing  assets  teztually  in  terms  of  the  CDM.  AIL  ^>ecification  are 
import anti  oq)orteQ  by  libraries  to  efiect  asset  interchange.  The  AIL  is  an  interim  language  that  will  be 
superceded  by  the  long-term  asset  interchange  solution. 

The  long-term  approach  to  asset  interchange  will  require  the  following: 


A  library-independent  textual  notation  for  representing  library  data  models  in  terms  of  a  common  meta-data 
model 

A  library-independent  toctual  noution  for  representing  asset  descriptions  in  terms  of  a  particular  library  data 
model 

A  transfer  envelope  to  encapsulate  library  dau  model  specifications,  asset  description  specifications,  and  asset 
contents 


The  ALOAF  is  assessing  a  number  of  existing  standards,  such  as  CDIF,  IRDS,  and  SGML,  for  their  applicability  to 
these  laner  three  needs. 
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ALOAF 

ALOAF  SPECIFICATIONS  (2) 
COMMON  DATA  MODEL 


Qass  N^e 


Fit* 


Name  —  FileJ 

Alteinate_Name  —  Ij_Pa 

Version 
Release_Date 
Restiictroas_Apply 
U_Composti_Of  [FtUl 
Is_AnAtsror_df  [Asset} 
ls_Deseendant_Of  [Asstt! 
Rtquins  [AssaJ 
Is_RequFtd_By  [Assetj 
Vas_Crtaied_By  [Organitadonj 
lsJJndtrslood_^  [Petson! 


—  FiIe_Name 

—  lt_PanjOf  [Asset] 


Organization 


—  Name 

—  Alteniate_Name 

—  Address  ” 

—  ■Ielephone_Numbei 

—  Created  [Assetj 


—  Name 

—  Address 

—  ■Ielephone_Number 

—  £lectronic_Mai]_  Address 

—  ls_CoiUact_For  [Asset] 
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This  is  a  piooiial  representation  of  the  ALOAF  Conunon  Dau  Model  (CDM).  It  consists  of  a  rather  simple  class 
hierarchy,  with  a  class  called  Object  at  the  root  of  the  hierarchy.  There  are  a  couple  of  attributes  used  for  essentially 
bookkeeping  purposes  defined  in  the  Objea  class,  and  these  attributes  are  inherited  by  the  other  classes  m  the 
model 

The  hean  of  the  Common  Dau  Model  is  the  Asset  class.  It  has  a  variety  of  attiibotes  to  describe  various  general 
properties  of  assets.  The  attributes  at  the  top  of  the  list,  in  the  standard  font,  have  integer  or  string  values.  The 
attributes  in  italics  represent  relationsh^  emanating  from  the  class,  with  the  target  class  of  each  relationship  noted 
in  brackets. 

The  Organiation,  and  Person  classes  are  intended  to  supplement  the  Asset  class  by  providing  infonnation  about  the 
organizations  and  pet^le  who  created  or  are  points  oi  oontaa  for  assets.  The  File  class  exists  to  represent 
information  about  the  files  that  constitute  the  “contents”  of  an  asset. 

Using  the  Common  Dau  Model  assets  are  represented  as  objects  that  are  instances  of  CDM  classes.  A  typical  asset 
might  be  represented  by  a  single  Asset  object,  one  (or  possibly  more)  Organization  objects,  one  (or  possibly  more) 
Person  objects,  and  one  or  more  F3e  objects,  all  related  to  one  another  appropriately  through  the  CDM  relationship 
attributes. 
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ALOAF 

STATUS  AND  PLANS 


•  Version  0.5  Completed  in  August,  Distributed  for  Review 

-  Common  Data  Model  and  Interim  Asset  Interchange  Language 
Defined 

-  Initial  Asset  Interchange  Experiment  Undeiway,  Based  on  Above 

•  Version  0.8  Now  Available,  Review  Strongly  Encouraged 

-  Meta<Data  Model  Selected 

-  M^ority  of  Services  Defined  in  Language  Independent  Form 

•  Version  1.0  Available  in  Februaj^  92 

-  Complete  Set  of  Core  Services 

-  More  Complete  Asset  Interchange  Specification 

•  Subsequent  Periodic  ALOAF  Updates 

-  Reflecting  Comments,  Lessons  Learned,  Standards  Evolution 

•  Initial  ALOAF  Server— Summer  92 

ALOAFIO^-Ga 


This  slide  provides  infnrmatinn  about  the  current  status  of  the  ALOAF  and  our  plans  for  its  future  development, 
panicolarty  during  1992. 

Version  0.5  of  the  document  was  completed  in  Angust  and  was  distributed  to  a  limited  set  of  individuals  for  review. 
Version  0.5  included  the  Common  Data  Model  (CDM)  and  the  interim  Asset  Interchange  Language  (AIL)  to 
facilitate  initial  asset  interchange  ecperimentation.  An  initial  asset  interchange  capability  has  been  developed  based 
on  the  CDM  and  AIL;  that  capability  was  demonstrated  at  'TRI- Ada  and  an  improved  version  is  being  demonstrated 
here  at  STARS  ’91. 

Version  0.8  of  the  document  is  now  available  for  STARS  *91  attendees  to  take  home  with  them.  We  strongly 
encourage  those  who  do  a  copy  to  review  it  and  provide  ns  with  comments.  In  Version  0.8,  the  initial  ALOAF 
meta^dau  model  is  defined,  and  a  majority  of  the  services  in  the  Service  Model  have  been  defined  in 
programming-language-independeot  form. 

ALOAF  Version  Ifiwfli  be  available  in  Fdmiary  1992.  It  is  eapected  to  specify  an  the  core  services.  Itsbouldalso 
contain  a  more  complete  Asset  Interchange  Spoificatiofl,  including  either  the  library  data  model  represenution,  the 
asset  description  representation,  or  both.  Version  14)  wfll  be  considered  the  baseline  against  udiich  inidai  ALOAF 
service  implementation  wiU  be  performed- 

Beyond  Version  1.0,  the  document  wfll  be  updated  pcriodicaUy  to  reflea  both  intetnal  and  external  comments, 
lessons  learned  through  ALOAF  implementation  and  experimenution,  and  evolutkm  of  related  standards.  Among 
the  first  things  to  be  done  after  Vetsioa  IJ)  wfll  be  the  ^jecification  of  Ada  service  interfaces. 

SAiC,  under  subcontraa  to  IBM,  wfll  be  producing  the  initial  ALOAF  implementation  in  the  Summer  1992 
timeframe.  This  implementation  wfll  be  an  ALOAF  server,  providing  service  access  via  a  client-server 
oommnnications  protocol. 
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aloaf 

ASSET  INTERCHANGE  EXPERIMENT 


BEGIN 

Enter  library  A 
Searcn  for  aasct 


■  En»r  library  B 

■  SeaitMor  asset 
-  rmd  asset 

'  Export  asset  via  AFS 


Import  asset  via  Af  S 
Extraa  asset  for  reuse 


ALOAricjtn'*vi3 


As  noted  in  the  previous  slide,  we  have  been  conducting  an  initial  asset  irteichange  experiment  based  on  the 
Common  Data  Model  (CDM)  and  Asset  Interchange  Language  (ADL).  The  Unisys  and  IBM  asset  library 
mechanisms  have  been  modified  to  eiqmrt  and  import  asset  descriptions  using  the  AIL  This  figure  illustrates  the 
basic  interchange  scenario  that  is  being  used. 

At  the  top  we  see  a  workstation  having  access  to  both  a  Uni^  RLF  library  and  an  IBM  AMS  library  via  the 
Internet.  (Note  that  the  worirstation  and  library  sites  also  have  access  to  AFS,  the  wide-area  network  file  ^em 
produa  from  Hansarc  Corporation.  AFS  enables  all  sites  to  directly  access  a  common  set  of  files  across  the 
Internet.)  In  this  scenario,  a  user  (for  example,  a  library  administrator),  searches  for  a  particular  asset  or  class  of 
assets  in  Library  A,  but  finds  none.  Thinking  it  desirabie  to  have  such  a  class  of  assets  installed  in  Library  A 
(perhaps  because  Library  A  is  at  the  user's  local  site),  the  user  accesses  Library  B  and  conducts  an  analogous  search 
in  that  library.  Upon  finding  a  suitable  asset,  the  user  exports  the  asset  by  generating  an  AIL  spedficatior.  describing 
the  asset  and  placing  it  in  an  AFS  file  (the  files  constituting  the  contents  of  the  asset  are  also  accessible  via  AFS). 
The  user  then  switches  back  to  Library  A  and  imports  the  asset  using  the  AIL  q>ec,  thus  making  the  asset  directly 
available  to  other  usen  of  Library  A 

We  have  found  this  style  of  asset  interchange  to  be  usefuL  but  not  completely  satisfying,  primarily  because  the 
Common  Data  Model  describes  only  general  charaaeristics  of  assets,  rather  than  their  detailed  domain-spedfic 
charaoeristics.  However,  extending  the  Connnon  Data  Model  to  accommodate  all  domains  would  render  it 
enormous,  unwieldy,  and  very  difficult  to  understand.  What  is  needed  is  a  capability  to  describe  individnal  library 
data  models  in  accordance  with  a  particular  meta-data  model,  so  that  exported  assets  can  be  described  in  terms  of 
their  native  data  models.  This  will  provide  the  human  performing  asset  impon  with  a  more  complete  and  focused  set 
of  information  about  the  asset  to  facilitate  some  of  the  more  difficult  aspects  of  asset  import,  such  as  asset 
classification.  Such  an  approach  is  highly  consistect  with  the  long-term  ALOAF  asset  interchange  strategy- 
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A  key  aspect  of  the  ALOAF  approach  to  foster  standards  for  libiaiy  interoperability  is  the  STARS  relationship  with 
the  Reuse  Ubrary  Interoperability  Group  (RIG).  The  RIG  is  a  pre-standards  organization  that  is  pnisning  objectives 
generally  similar  to  those  of  the  ALOAF.  However,  the  RIG  features  a  much  broader  base  of  participation,  with 
over  20  organizations  currently  involved.  You  are  encouraged  to  pick  up  a  copy  of  'he  RIG  press  release  here  at 
STARS  *91  to  learn  more  about  the  organization. 

STARS,  ASSET  and  CARDS  are  among  the  organizations  that  are  actively  participating  in  RIG  activities.  Several 
individuals  with  direa  STARS  affiliations  are  working  actively  in  RIG  technical  subcommittees.  Also,  it  is  worth 
noting  that  STARS  (including  ASSET)  was  instrumental  in  founding  the  RIG  earlier  this  year. 


ALOAF 

RELATIONSHIP  TO  RIG 


The  Reuse  Library  Interoperability  Group  (RIG)  is  Pursuing 
Objectives  Similar  to  ALOAF,  With  Much  Broader  Participation 

STARS,  ASSET,  and  CARDS  are  All  Well  Represented  in  RIG 

-  STARS  Instrumental  in  Founding  RIG 

Little  Direct  Overlap  Between  RIG  and  ALOAF  Efforts  at  Present 

-  RIG  Emphasmng  Asset  Interchange  Via  Standard  Data  Model 

-  ALOAF  Currently  Focused  on  Library  Services,  Meta-Model 
Approach  to  Asset  Interchange 

ALOAF  Concepts  Being  'D^sitioned  Into  RIG  as  Appropriate 

-  e.g.,  Initial  Common  Data  Model,  Meta-Model  Concepts 

ALOAF  Team  Will  Incorporate  RIG  Results  When  Available 

-  Ensure  Broad  ALOAF  Applicability 

-  Help  Validate  RIG  Results 


AuaAriCimivci4 


At  the  preseat  time,  there  is  little  direa  ovetuq?  in  the  work  that  the  RIG  and  the  ALOAF  are  each  actively 
pursuing.  The  RIG  is  currently  emphasizing  asset  interchange  via  a  standard  data  modeL  although  th^  are 
oonsideiing  meta-model  issues  relating  to  asset  interchange,  as  well.  The  ALOAF  has  already  visited  the  issue  of 
asset  interchange  via  the  Common  Data  Model  and  has  condnaed  some  live  experiments,  but  the  ALOAF  efforts 
appear  less  ambitions  than  the  RlG’s  in  this  area.  On  the  other  hand,  the  ALOAF  is  now  actively  developing  an 
extensive  set  of  Ubrary  services  and  is  moving  forward  relatively  aggresstvely  on  meta-model  based  asset  interchange. 


The  two  efforts  thus  appear  to  be  oomplementary  at  this  time,  with  the  ALOAF  pushing  the  frontiers  of  library 
interoperabSity  and  offering  its  results  for  RIG  consideration,  wiiile  the  RIG  is  playing  the  more  conservative  role  of 
identifying  areas  that  are  ready  for  standardization  and  fleshing  out  candidate  standards  in  those  areas.  ALOAF 
team  members  will  continue  to  work  directly  with  the  RIG  to  transition  ALOAF  results  as  appropriate,  and  will  also 
be  poised  to  incorporate  RIG  results  back  into  the  ALOAF  when  they  become  available.  In  this  latter  role,  STARS 
will  ensure  that  ALOAF  appUcability  extends  beyond  just  the  STARS  Ubrary  mechanisms,  and  wiU  also  aa  as  a 
testbed  to  help  vaUdate  RIG  results. 
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ALOAF 

STARS  COMMUNITY  INVOLVEMENT 


•  We  Need  Input  and  Feedback  A^a: 

-  Review  of  the  ALOAF  Document 

-  Trial  Use  of  Current  STARS  Library  Mechanisms  and  Future 
ALOAF-Compliant  Mechanisms 

•  Input  From  a  Variety  of  Perspectives  is  Desired 

-  Library  Mechanism  Developers 

-  Reuse  Tool  Developers 

-  Reuse  Library  Designers 
-*  Library  End  Users 

-  Standards  Organizations 

-  The  Software  Engineering  Community  in  General 


In  closing,  I  would  like  to  extend  a  call  for  you  and  your  organizations  to  contribute  to  the  ALOAF  c3on  by 
becoming  directly  involved  as  TT  aSBliates  or  simply  by  taking  the  time  to  review  the  ALOAF  document  and  provide 
us  with  comments.  We  need  input  and  feedback  in  a  variety  of  forms,  ranging  from  review  of  the  document  to  trial 
use  of  the  current  STARS  library  mechanisms  with  asset  interchange  capabilities  and  the  future  fully 
ALOAF-compliant  Ubraty  mechanisms. 

Also,  we  would  like  feedback  on  the  ALOAF  from  a  variety  of  pei^>ectives,  including  libraiy  mechanism  developers, 
developen  of  ALOAF  client  tools,  reuse  library  designers  and  data  modelers,  library  end  users  impaaed  by  asset 
interchange  and  seamless  interoperability,  related  standards  organizations,  and  the  software  engineering  community 
in  general,  which  is  grappling  with  smiilar  but  more  complex  issues  in  the  area  of  SHE  frameworks. 
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STARS  Library  Mechanisms: 
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STARS  LIBRARY  MECHANISMS: 
OUTLINE 


•  Definition  and  roles 

•  Multiple  Approaches 

•  Common  characteristics 

•  Diflerentiating  characteristics 

•  Reusability  Library  Framework  (RLF) 

•  Asset  Management  System  (AMS) 

•  Reusable  Object  Access  and  Management  System  (ROAMS) 

•  What  do  we  want  you  to  do? 


By  this  time  in  STARS’91,  and  indeed  in  the  STARS  progranu  I  hope  that  you  know  something  about  the  STARS 
library  mechanisms.  If  you  have  not  yet  seen  the  current  versions  dcmonstiated  here,  1  encourage  you  to  do  so. 

My  purpose  is  not  to  describe  the  mechanisms  in  detail  but  rather  to  talk  about  the  role  of  library  mechanisms  in  our 
concept  of  reuse-based  development,  why  we  have  multiple  mechanisms,  and  the  common  chaiaaeristics  among  the 
stars  library  mechanisms.  Then  for  ea^  of  the  mechanisms  I  will  discuss  the  charaaeristics  that  diSerentiute 
among  them.  I  will  also  present  summary  information  about  the  use  of  the  mechanisms  thus  far  and  the  material 
available  to  support  their  further  use  and  r  aluation  by  STARS  affiliates. 
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STARS  LIBRARY  MECHANISMS; 
DEFINITION  AND  ROLES 


•  Asset  Library  Mechanism:  Asset  Library  Framework  +  Tools 

•  Asset  Library  Mechanisms  support  processes  in  all  reuse 
process  families 

-  Collecting,  organizing,  and  characterizing  reusable  assets 

-  Making  asset  information  available  to  a  user 

-  Accumulating  metrics  and  feedback  about  assets  and  the  library 

•  Asset  Library  Mechanisms  support  various  user  roles 


STARS 


As  yon  have  seen  in  the  earlier  ALOAF  presentation,  we  define  an  asset  library  system  or  library  mechanism  to 
con^  of  a  set  of  framework  services  plus  tools.  The  fiamework  services  provide  for  basic  operations  on  library  dau 
models  and  asset  infonnation.  The  tools  aggregate  and  sequence  services  to  provide  higher  level  capabilities. 


A^t  libraiy  mechanisms  su}^n  processes  in  all  of  the  reuse  process  famiiifc  identified  in  the  Reuse  CONOPS. 
They  suppoii  the  domain  analysts  and  asset  developers  in  capturing  models  and  assets.  They  support  the  library 
managers  in  orgaruzing  and  characterizing  assets.  They  enable  the  software  engineers  who  need  the  assets  to  search 
for  and  understand  them.  They  also  provide  a  means  for  accumulating  information  about  the  assets  and  the  library 
operation  that  is  fed  back  into  the  planning  and  management  function. 


Because  it  supports  these  multiple  processes  and  roles  of  a  reuse  operation,  the  library  mechanism  can  can  be  seen, 
tt^ether  with  the  library  data  model,  as  the  means  to  bind  the  processes  together  by  facilitating  the  capture  and 
disemination  of  information  about  the  domain,  the  assets,  and  the  reuse  operation. 
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STARS  LIBRARY  MECHANISMS 
MULTIPLE  APPROACHES 


Unisys:  Reusability  Library  Framework  (RLF) 

-  Formally-Encoded  Domain  Models;  knowledge  based  tools 

-  Developed  in  Ada  under  the  STARS  foundations  program 

IBM/SAIC/SPS:  Asset  Management  System  (AMS) 

-  Multiple  Gassiflcation  Schemes;  user-friendly  definition 

-  Derived  from  SPS’s  Automated  Reusable  Components  System 
(ARCS) 

Boeing/DEC:  Reusable  Object  Access 
and  Management  System  (ROAMS) - 

-  Object-oriented/extensible  repository 

-  Uses  commercial  SEE  framework  to  achieve  tight  integration 

-  Derived  in  part  from  Boeing’s  initial  repository  experience 


The  three  STARS  libiaxy  mechanisms  arc  RUv  AMS,  and  ROAMS.  The  Unisys  Reusability  Libiaiy  Ramework 
(RLF)  is  motivated  by  ih',  notion  that  formally-enooded  domain  models  and  associated  tools  are  fundamental  to 
domain  specific  reuse.  It  supports  knowledge  based  techniques.  RLF  was  initiated  and  has  been  evolved  under  the 
STARS  program  over  the  pak  four  years. 

The  IBM  team’s  library  mechanism  is  the  Asset  Management  System  (AMS).  AMS  is  guided  by  the  notion  that 
multiple  classification  techniques  and  search  modes  are  needed  to  support  varions  domains,  and  that  classification 
scheme  definition  should  be  supported  through  a  user-friendly  interfhk.  AMS  is  derived  from  the  SPS  ARCS,  which 
was  developed  under  Army  CECOM  SBiR  program. 

The  Boeing  Reusable  Olqea  Access  and  Management  System  (ROAMS)  provides  an  object  oriented  libiaiy 
capability.  It  achieves  tight  integration  of  the  library  with  the  SEE  by  being  implemented  as  extensioas  of  the  DEC 
COHESION  and  Common  Data  Dictionary  products.  It  is  based  in  part  on  Btking’s  earlier  STARS  rq>ositoiy 
prototype. 
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STARS  LIBRARY  MECHANISMS: 
ADVANTAGES  OF  MULTIPLE  APPROACHES 


•  Evaluation  of  different  approaches  to  reuse  and  supporting  technology 

•  Maturation  of  technology  through  application 

•  Investigation  of  interoperability  among  heterogeneous  libraries 

•  Examination  of  different  degrees  of  integration  of  the  library 

mechanism  with  the  SEE 

-  Stand-alone  library 

-  Integrated  into  framework 

•  STARS  strategy  is  to 

-  Evaluate  the  mechanisms  in  the  context  of  reuse 

-  Development  scenarios 

-  Standardize  on  ALOAF  specifications 

STAAS  Lihfmfy 


Becanse  little  rense-based  development  has  been  done  thus  far,  there  is  a  lack  of  ocpeiience  from  which  to  draw 
requirements  for  reuse  processes  and  their  supporting  tools.  However,  given  the  widespread  conviction  that  effective 
reuse  is  key  to  improved  software  engineering,  several  reuse  library  ^ems  have  been  developed,  both  inside  and 
outside  of  STARS.  These  mechanisms  vaj^  from  each  other  in  ma;^  ways,  reflecting  different  hypotheses  about  how 
to  best  support  reuse-based  software  engineering. 

Although  the  STARS  mechanisms  have  been  used  to  capture  domain  information  and  assets,  and  to  support  the 
STARS  primes  in  accessing  and  exchanging  assets,  th^  have  not  yet  been  practically  used  to  support  reuse-based 
development  or  maintenance  of  software  systems.  This  is  by  and  large  true  of  other  library  mechanisms  as  well,  with 
the  notable  exception  of  the  CAMP  library.  There  is  also  little  oqxrience  with  the  use  of  libraries  to  support  domain 
^>ecific  reuse  or  to  manage  many  different  types  assets. 

We  believe  that  it  is  advantageous  to  apply  different  mechanisms  in  realistic  scenarios,  so  that  we  can  understand 
how  the  charaaehstics  of  library  mechmiians  affect  reuse.  We  want  to  see  how  different  classification  techniques 
affect  asset  retrieval.  We  want  to  understand  what  impaa  architecture  orientation  and  the  nature  of  the  domain  have 
on  library  mechanism  requirements. 

Our  pursuit  of  multiple  library  mechanisms  today  enables  us  not  only  to  evaluate  different  approaches  in  internal 
and  affiliate  applications,  but  in  so  doing  to,  to  mature  different  technologies.  The  maturation  will  allow  the 
mechanisms  to  be  applied,  and  thus  more  thoroughly  assessed  for  their  effectiveness,  in  the  STARS  demonstration 
projects  and  beyond. 

The  existence  of  multiple  library  mechanisms  within  the  SIARS  program  enables  us  to  prototype  and  experiment 
with  the  ALOAF  interoperability  provisions,  concurrently  with  their  development  We  are  also  in  a  position  to  look 
at  the  effea  of  different  degrees  of  library  integration  into  a  SEE. 

The  STARS  strategy  is  to  continue  to  pursue  multiple  approaches  to  providing  library  support  to  evaluate  the 
mechanisms  in  the  context  of  reuse-based  development  and  maintenance  operations,  and  to  implement  the  ALOAF 
standards  in  the  library  mechanisms.  We  will  thus  achieve  interoperability  among  the  STARS  library  systems  and 
promote  the  sharing  of  reuse  tools  while  we  are  gaining  experience  about  the  impaa  of  library  mechanism 
charaaeristics  on  the  reuse  processes. 
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STARS  LIBRARY  MECHANISMS: 
COMMON  CHARACTERISTICS 


•  Library  data  model  tailorable  to  domain  and  organization 

•  Support  the  STARS  standards  portfolio  interfaces 

•  Open  interfaces  for  reuse  and  other  tools 

•  ALOAF  conforming 

-  Asset  interchange 

-  Services  providing  tool  interface 


SLUBLIirwi  Uiitmmmm'Hti/tnW 


Important  common  characteristics  of  the  STARS  library  mechanisms  are  shown  here.  All  STARS  library  medianisms 
support  user  definidon  and  modiScation  of  the  library  data  model  This  means  that  the  data  model  can  readily  be 
tailored  to  a  specific  domain  and/or  to  a  ^lecific  organization  to  accommodate  the  kinds  of  assets  and  kinds  of 
information  needed. 

Each  of  the  libr^  mechanisms  will  snpport^tegrate  the  qpen  interfaces  supported  by  the  STARS  (and  the  prime) 
SEE,  as  appropriate.  The  STARS  Standards  Portfolio  ident£es  those  interface  which  indude,  for  ezample, 
X'Windos^ 


Each  libraty  mechanism  today  has  open  interfaces  to  the  library  services  so  that  reuse  tools,  and  other  tods,  can 
utilize  those  services. 


Each  libraty  mechanism  will  be  ALOAF  conforming  and  thus  able  to  interoperate  with  the  other  STARS 
libraties— exchanging  assets  and  enabling  direct  access  to  assets  by  the  other  primes'  tools. 


STARS  LIBRARY  MECHANISMS: 
DIFFERENTIATING  CHARACTERISTICS 


•  Domain  Modeling/ Asset  Classification  technique 

•  User  Interface 

•  Search  Mode 

•  Asset  Inspection 

•  Platform 

•  Maturity 


iJAja  tMmr  MtdmamJHmitIVO 


Other  charaaeristics  vary  across  the  STARS  library  ^ems  and  help  to  differentiate  ar"''ng  them.  The  first  four  are 
characteristics  whose  impact  we  wish  to  understand  better.  The  last  two  may  influence  the  Choice  an  affiliate  would 
mahe  in  selecting  a  libraiy  mechanism  for  evaluation. 
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STARS  LIBRARY  MECHANISMS 
RLE 


•  Domain  Modeling/ Asset  classification  technique 

-  Structured  inheritance  network 

-  Class/object  hierarchy,  arbitrary  relationships/attributes, 
multiple  Inheritance 

-  Accommodates  variety  of  classification  methods  e.g., 
taxonomic,  faceted,  keyword 

-  Rules  to  capture  domain  heuristics,  provide  user  guidance 

•  User  Interface 

-  X'Windows;  graphical  presentation  of  network  hierarchy 

•  Search  Mode 

-  Browse  through  displayed  network 

-  Textual  Query 

-  Rule-based  guided  search 


rtAHS  Lttmf  Ht 


The  RLF  provides  tbe  capat^^  to  define  and  store  a  dass/ol^ect  hieraxd^  with  user  determined  relationships  and 
attributes  and  with  multiple  inheritance.  It  can  be  used  to  implement  a  variety  classifications  methods  for  assets.  It 
also  provides  a  knowledge-based  capability  in  that  rules  may  be  associated  with  the  nodes  of  the  network  and  used  to 
provide  user  guidance  for  traversing  the  network. 

The  user  interface  is  organized  ptiinaiily  around  a  graphical  presentation  of  the  netwo^  hierarchy.  At  each  network 
node  RLF  provides  a  ccmtezt-sensiiive  set  of  commands  to  support  browsing,  inspection,  and  retrieval  of  libraiy 
assets. 

The  search  modes  that  are  sup^ported  by  RLF  include  the  capability  to  browse  through  the  network  by  pointing  and 
cliclring.  A  textual  query  capaidity  and  the  assist  mode  of  role-bas^  guidance  also  fagiiitati»  search.  The  asset 
inqKCtion  capability  of  the  RLF  enables  the  user  to  in^>ect  tactual  information  such  as  abstracts,  source  code,  and 
documentation.  It  also  has  mechanisms  to  invoke  axer^  tools  to  provide  other  ways  of  understanding  an  asset  such 
as  looking  at  design  diagrams  or  doing  an  on-line  test  of  the  asset.  O^er  special  functionality  provided  by  the  RLF  is 
the  ability  to  import  and  export  assets  in  accordance  with  the  current  asset  occhange  roecification  that  is  a  pan  of 
ALOAF. 
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STARS  LIBRARY  MECHANISMS: 
RLE 


•  Asset  Inspection 

-  Mechanisms  to  inspect  textual  asset  information  e.g.,  abstract, 
source,  documentation 

-  Mechanisms  to  invoke  external  tools  to  analyze  other  asset 
information  e.g.,  to  display  design  graphics,  inspect 
formatted  documents 

•  Other  Functionality 

-  Import/export  of  assets 


STAMS  LAmrf 
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STARS  LIBRARY  MECHANISMS; 
RLE  USER  INTERFACE 


STARS  LIBRARY  MECHANISMS: 
RLE 


•  Current  Platforms: 

-  Sun  3,  Sun  4 

-  Depends  on  Unisys  STARS  Reusable  Graphical  Browser  and 
Ada/Xt  Products 

•  Status 

-  RLF  23  currently  available 

-  RLF  3.0  demoed  at  STARS  ’91  and  available  late  December  ’91 

-  Improved  modeling  and  browsing  capabilities 

-  Greater  integrability  with  external  tools 

-  Key  1992  enhancements 

-  Improved  documentation 

-  Improved  attribute  structure  browsing,  query  capabilities 
and  rule-based  capabilities 

-  ALOAF  compliance 


Tile  platforms  on  which  RLF  currently  runs  are  Sun  3  and  Sun  4  workstations  with  SunOS  4.1  (and  later  versions) 
and  the  Verdix  6.03  Ada  compiler.  The  RLF  depends  on  two  other  Uni^  STARS  products,  the  Reusable  Graphical 
Browser  and  the  Ada  XT  implementatiaaL 


Verson  23  of  RIF  is  cur.'ently  available.  The  version  that  you  see  here  at  STARS  91  will  be  available  by  the  end  of 
this  year.  Over  the  next  year  several  existing  capabilities  of  the  RLF  will  be  enhanced  and  the  RLF  will  be  made 
compliant  with  the  ALOAF  asset  interchange  ^  service  specifications. 
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STARS  LIBRARY  MECHANISMS; 
RLE 


•  Application  thus  far 

-  Air  Force  CARDS  Command  Center  Domain  Model  and  Architecture 

-  Naval  Research  Laboratory  Navy  Tactical  Command  and 
Control  Library 

-  Unisys  IR&D  Ada  Library 

-  Unisys  IR&D  Anti-Submarine  Warfare  (ASW)  library 

-  Unisys  Domain  Model  of  Ada/Xt  software 


•  What  is  available  to  work  with 

-  RLF  source,  binary,  documentation 

-  User  manuals 

-  Example  libraries 

-  Anti-submarlae  warfare 

-  Ada.OCi 

-  Ada  benchmarks 


STAK  Limy 


The  RLF  has  been  used  by  people  other  than  its  developers  in  several  applications  as  shown  in  this  slide.  It  is  the 
libruy  mechanism  supporting  the  Air  Force  CARDS  litnaiy,  an  operational  libtaiy  that  you  will  be  hearing  more 
about  in  the  next  presentation. 

The  material  available  to  potential  users,  in  addition  to  the  RLF  software  and  associated  documentation,  consists  of 
oser  mamiak  and  examples  of  the  library  data  models  that  have  been  constmaed  using  RLF.  There  are  user  tnannals 
for  the  graphical  browser,  for  the  librar^  for  data  model  construction  and  for  rule  base  construction. 
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STARS  LIBRARY  MECHANISMS: 

AMS 

•  Domain  modeling/asset  classiCcation  technique 

-  Object-oriented  class  hierarchy,  arbitrary  relationships/attributes 

-  Faceted  (controlled  vocabulary) 

-  Keyword  indexing  (uncontrolled  vocabulary) 

-  Text  indexing 

•  User  interface 

-  X-windows  indented  tabular  presentation  of 
classification  hierarchy 

•  Search  mode 

-  Forms  based  query 

-  Textual  query 

-  Browse  through  taxonomy 

-  Relationship  traversal 

The  domain  modeling  and  asset  classification  technicpies  offered  by  the  AMS  are  based  on  an  objea  oriented  dass 
hierarchy  that  allows  for  arbitrary  relationships  and  attribntes  associated  with  the  objects.  The  AMS  provides  explicit 
support  for  the  faceted  classification  technique  that  was  discussed  in  yesterda/s  bri^g  on  the  Domain  Analysis 
Process  Model.  It  also  provides  for  indexing  of  keywords  and  of  textual  material  associated  with  an  asset. 

The  user  interface  presents  classification  information  is  tabular  form.  Search  modes  currently  supported  by  AMS  are 
form  based  queries  and  textual  queries.  AMS  also  supports  browsing  through  the  object  collection  based  on  user 
defined  taxonomies  and  traversal  of  the  objea  base  using  attribute  relationships  within  the  data  model.  The  asset 
inspection  capabiliues  allow  for  display  of  textual  information  and  for  the  display  of  graphic  information  by  ;r/.cgrated 
design  tools. 

The  AMS  currently  supports  the  import  and  oqxirt  of  the  classification  hierarchy,  Le.,  the  data  model,  as  well  as  the 
asset  information. 
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STARS  LIBRARY  MECHANISMS: 
AMS 


•  Asset  inspection 

-  Textual  files 

-  Graphics  displays  via  integration  with  design  tools 

•  Other  functionality 

-  Import/export  of  classification  hierarchy 

-  Import/export  of  assets 
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STARS  LIBRARY  MECHANISMS: 
AMS  CLASSIFICATION  TECHNIQUE 


STARS  LIBRARY  MECILANISMS: 
AMS  USER  INTERFACE 


STARS  LIBRARY  MECHANISMS: 
AMS 


mmE 


•  Current  Platforms:  IBM  RISC/6000  AIX,  Sun 

•  Status: 

-  Currently  single  user  beta  version 

-  Key  1992  enhancements 

-  Multi-user  ALOAF  compliant  version  available  7/92 

-  Commercial  release  by  SAIC/SPS  9/92 

•  Application  thus  fan 

-  Naval  IVaining  Systems  Center  flight  simulation  reuse  library 

•  What  is  available  to  work  with? 

-  Beta  test  software  under  license  from  SPS 

-  Product  defuiition  document  for  asset  management  system 

-  Preliminary  User’s  Guide 

-  Flight  simulator  domain  vocabulary  document 

tZAJB thrtmmtmlHmk/VCU 


The  AMS  coirently  nuu  on  the  IBM  RISC/6000  AIX  workstation  and  on  Sun  3  workstations  nsing  the  Verdix 
compiler. 

The  version  of  AMS  that  you  are  seeing  demonstrated  is  a  sin^e  user  Beta  version.  During  1992  a  mnlti-oser 
ALOAF  compliant  version  will  be  devel(^)ed,  with  a  commercial  release  plaimed  for  next  fall. 

The  AMS  has  been  used  on  a  Naval  Thuning  Systems  Center  reuse  library  for  the  flight  simulation  domain. 

Material  that  is  available  to  potential  users  of  the  AMS  is  the  Beta  :est  software  under  license  bom  SPS,  a  product 
definition  document  that  describes  AMS  user  capabilities,  and  a  preliminary  users  guide.  An  example  of  a  domain 
specific  library  built  using  AMS  is  also  available  in  both  document  and  classification  scheme  impon  format. 
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STARS  LIBRARY  MECHANISMS: 
ROAMS 


•  Domain  Modeling/classification  technique 

-  Object-oriented  class  hierarchy,  arbitrary  relationships/attributes 

-  Supports  various  classification  methods 

•  User  interface 

-  X-v»Tndows  based 

-  Seamless  extension  of  COHESION  user  interface  for  SEE 

•  Search  mode 

-  Browse  class  hierarchy 

-  Traverse  relationships  via  static  links 

-  Graphical  (icon-based)  browsing 


n4JtS  lAw,  MtdMM/Hak/VC;* 


The  domain  modeling  dasstfication  technique  supported  by  ROAMS  is  also  an  objea-oriented  dass  hierarchy  that 
allows  for  arbitrary  relationships  and  attributes.  It  also  sup^rts  various  classification  methods  determined  by  the 
needs  of  the  domain.  ROAMS  does  come  with  a  “starter”  library  data  model  for  which  some  oqplidt  special  support 
is  provided. 

The  user  interface  of  ROAMS  is,  like  the  others,  X-windows  based.  It  is  an  extension  of  the  COHESION  user 
interface  of  the  Boeing  SEE. 

The  search  modes  supported  by  ROAMS  allow  a  user  browse  the  da«  hierarchy,  to  traverse  relationships  among 
assets  through  links  in  the  data  model,  and  to  browse  through  the  library  by  clicking  on  icons  associated  with  asset 
types. 

Asset  inspection  within  ROAMS  is  provided  by  the  COHESION  framework  capabilities  for  presentation  of  textual 
and  graphical  material  and  also  by  the  COHESION  framework  capability  for  invocation  of  tools  that  can  provide 
other  views  or  means  of  understanding  assets. 

Other  functionality  currently  supported  by  ROAMS  is  that  which  facilitates  keeping  track  of  and  manipulating 
derivatives,  alternates  and  versions  of  assets  within  the  library. 
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STARS  LIBRARY  MECHANISMS: 
ROAMS 


•  Asset  inspection 

-  Uses  COHESION  presentation  capabilities  for  text  and 
graphics  display 

-  Uses  COHESION  control  integration  capabilities  for  transparent 
tool  invocation  based  on  type  of  asset  and  asset  descriptive  data 

•  Other  functionality 

-  Supports  asset  “derivatives”,  “alternates”,  and  “versions” 


SUJtS  MMmmm/iUtlenncat 
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STARS  LIBRARY  MECHANISMS: 
ROAMS  OBJECT  HIERARCHY  (PARTIAL) 


Asset  Version 
Ordered  Asset 
I —  Sub  Ordered  Asset 

I —  Document  Asset 

—  Requirements  Anal)-sis  Document 
—  Domain  Aniysis  Report 
— p  Manual  Asset 
—  User  Manual 
—  Installation  Guide 
' —  Software  Gsmponent 
Elementary  Code  Unit 
Ada  Gide  Unit 

I —  Ada  Spec  Unit 
' —  Ada  Body  Unit 
' —  Domain  Model 


-  Asset  Element 
I —  Document  Element 

-  User  Comment  Element 
f— r  Evaluation  Record 

—  Inspection  Record 
—  Metric  Analysis  Record 
—  Problem  Report 
-T  Domain  Model  Element 
—  ERA  Model 
—  Variation  Matrix 
•  Requirement 
[-r  Testing  Information 
—  Test  Plan 
—  Test  Actual  Output 
I —  Build  Instructions 
^  Legal  Entity 
Individual 
Library  Subscriber 


STAXS  LArmf 
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STARS  LIBRARY  MECHANISMS: 
ROAMS  USER  INTERFACE 


STAA 
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STARS  LIBRARY  MECHANISMS: 
ROAMS 

•  Current  platforms:  DEC  VAX/'VMS,  VAXstationA^S, 
DECstation/UIirix;  requires  DEC  COHESION 

•  Status: 

-  Currently  ROAMS  multi-user  client/server 
Demonstration  capability 

-  Key  1992  enhancements  for  prototype  capability 

-  Basic  repository  capability 

-  Keyword  search 

-  Primary  Ada  life  cycle  support  capability 

-  Hyper-text  browsing 

-  Rule-based  search 

•  Application  thus  far: 

-  Boeing/STARS  internal  use 

ROAMS  currently  runs  on  the  indicated  Digital  Equipment  platforms  and  requires  the  COHESION  framework. 

The  ROAMS  that  you  are  seeing  here  is  a  demonstration  capability.  In  the  next  year  ROAMS  will  be  evolved  into  a 
working  prototype  with  the  additional  capabilities  indicated  on  the  chart 

Thus  far  ROAMS  has  been  used  only  internally  by  the  Boeing  STARS  effort 

Material  available  to  understand  and  work  with  ROAMS  at  the  present  is  licensable  software  from  DEC  and 
associated  manuals.  That  is  augmented  by  the  ROAMS  ol^eo  hierarchy  design. 
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STARS  LIBRARY  MECHANISMS: 
ROAMS 


Wliat  is  available  to  work  with? 

-  Software: 

-  COHESION  (licensed  from  DEC) 

-  CDD/Repository  (licensed  from  DEC) 

-  Documentation: 

-  COHESION  Product  Manuals  (DEC) 

-  CDD/Repository  Manuals  (DEC) 

-  ROAMS  Object  Hierarchy  Design  (Boeing) 

-  Technical  alliance: 

-  Available  for  prime  afTtliates 


STAMS 


STARS  LIBRARY  MECHANISMS: 
WHAT  DO  WE  WANT  YOU  TO  DO? 


Bmm 


•  Become  a  technology  transfer  aiHliate 

•  Understand  what  we  have,  assess  it  through  use  in  your  environment, 
and  provide  feedback  to  us 

-  Ideally,  use  the  library  mechanism(s)  to  support  reuse-based 
development 

-  But  review  of  a  document,  or  one  capability  would  be 
a  contribution 


•  We  need  feedback  on 

-  User  interface 

-  Functionality 

-  Performance 

-  Reliability 

-  Effort  to  leam/use 

-  Completeness  and  usability  of  information  provided 

SJAja  MeAMB/Xalr/VCBt 


We  would  like  you  to  become  a  technology  transfer  affiliate  and  join  us  in  the  effort  to  accelerate  the  shift  to  domain 
specific,  reuse-based  software  development.  The  prime  teams  have  applied  the  evolving  libiaiy  mechanisms  intemally 
and  will  continued  to  do.  However  we  need  application  and  evaluation  from  a  spectrum  of  potential  users  to  guide 
the  evaluation  of  the  STARS  processes  and  mechanisms  towards  effective,  production  quality  products. 

We  would  like  to  have  the  library  mechanisms  applied  and  evaluated  in  the  contod  of  a  reuse-based  operation, 
etioompassing  many  life  cycle  activities.  But  we  welcome  lesser  contributions  such  as  the  review  of  documentation  or 
the  assessment  of  a  single  capabili^— for  erample  the  library  dau  model  construction  capability,  or  asset  browsing 
capability. 

We  seek  your  feedback  about  these  listed  chaiaaeristics  of  the  current  STARS  libraiy  mechanisms.  We  also  need 
your  input  about  additional  capabilities  or  features  of  the  library  ^ems  that  will  facilitate  reuse-based  software 
development. 
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ASSET 

OUTLINE 


•  Mission 

•  Facility 

•  Contents 


•  Infrastructure  for  an  industry 

•  Relationship  to  other  efforts 


Who  to  contact 


ASsrr/%tMr«/vc2 
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Congress  mandated  that  the  STARS  program  aeate  a  “National  Sofwaie  Technology  Repository”.  DARFA  responded  by 
creating  the  ASSET  project  and  awarding  it  in  January  1991  to  IBM  and  their  major  subcontractor  SAIC.  ASSET  is  in¬ 
tended  to  provide  a  focal  point  for  software  reuse  within  the  Department  of  Defense.  We  piaii  to  achieve  this  through  a  dis¬ 
tributed  network  of  reuse  libraries.  In  the  long  term,  we  believe  that  this  network  and  the  other  activities  of  STARS  and 
ASSET  will  act  as  a  catalyst  to  help  stimulate  the  development  of  a  national  industry  in  reusable  software  components  and 
ensure  that  the  needs  of  the  DoD  are  served  by  that  industry. 

We  perceive  three  roles  for  ASSET,  which  we  can  express  as  metaphors.  The  first  metaphor,  “marketplace,”  means  that 
asset  will  help  create  the  electromc  marketpUce  where  commerce  m  software  components  can  be  conducted  by  both  pub¬ 
lic  and  private  consumers  and  producers.  The  second  metaphor,  “brokerage,”  means  that  ASSET  will  actively  seek  to 
match  up  producers  and  consumers  in  this  marketplace.  The  third  metaphor,  “clearinghouse,”  means  that  ASSET  will  take  a 
leadership  role  in  stimulating  the  development  of  national  standards  which  will  enable  electronic  commerce  in  reusable 
components. 
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ASSET 

FACILITY 

_ _ _ i 

•  Location:  Morganto\vn,  VVV 

-  Excellent  telecommunications 

-  West  Virginia  University  (software  reuse  program) 

•  Computer  facilities 

-  Open 

-  Scalable 

-  4J  gigabytes  of  disk  storage 

-  Currently,  SRL  library  mechanism 

-  Investigating  new  technology  library  mechanisms 

aSSET/Mm/VCX 


The  first  instance  of  the  ASSET  repository  is  located  in  Morgantown,  WV.  Aside  from  other  advantages  like  a  generally 
low  cost  of  living.  West  Virginia  offers  ASSET  a  specific  advantage  in  its  excellent  state-of-the-art  telecommunications 
infrasmjtuire.  Fiber-optic  cabling  and  digital  phone  switching  are  common  throughout  the  state.  Morgantown,  in  patiicu- 
lar,  is  attractive  because  of  the  ongoing  software  reuse  program  at  West  Virginia  University  and  because  of  its  closeness  to 
the  Software  Engineering  Itisdiute  in  Pittsburgh 

Our  initial  computer  configuration  is  built  upon  an  open,  scaleable  archiiecture;  “Open"  because  it  is  built  upon  industry 
standards  like  POSIX  and  X;  “scalable"  because  it  is  configured  around  a  token  ring  peimtuing  the  easy  addition  of  process¬ 
ing  or  storage  resources.  Currently,  we  have  installed  42  gigabytes  of  direct  access  storage. 

Our  initial  library  access  mechanism  is  the  STARS  Reuse  Library  (SRL)  tool  prototype  developed  earlier  in  the  program. 
We  are  currently  investigating  newer  technology  mechanisms  and  plan  to  select  one  shortly. 
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ASSET 


FACILITY  (COM.) 


•  Communications 

-  Ten  2400/9600  baud  modems  for  dialup 

-  800  number 

-  Internet  access 

•  Staff:  Seven 


We  provide  communications  access  to  usen  via  both  diaJ-up  and  Inierneu  For  dial-up,  we  have  installed  ten  2400/9600 
bps  modems  which  can  be  reached  via  an  800  number.  Internet  access  is  provided  through  a  router  connected  to  a  regional 
network.  In  addition,  we  are  conducting  interoperability  experiments  via  direct  connection  to  other  reuse  libraries. 

The  current  suffing  at  ASSET  totals  seven  people  on  site  plus  additional  support  provided  by  other  IBM  and  SAIC  people. 
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ASSET 

CONTENTS 


Currently, 

-  STARS  Foundations  collection 

-  STARS  Primes  products 
Planned  emphasis: 

-  Ada  bindings  to  standards 

-  Cross-domain  components 

-  “Yellow  Pages”  -  like  directory  service 


ASSETAIoai/VCt 


ASSET  has  been  operaiional  for  less  than  three  months, 
capabilities. 


so  it  is  imponant  to  differentiate  current  capabilities  from  planned 


Currently.  ASSET  provides  access  to  the  STARS  Foundations  collection  and  to  selected  products  of  the  STARS  Primes 
contracts.  ASSET  win  provide  additional  services  to  STARS  program  personnel  and  to  Technology  Transfa  AfTiliatcs. 

In  adding  to  our  collection,  we  plan  to  emphasize  Ada  bindings  to  standards  and  cross-domain  components.  In  our  experi¬ 
ence.  A^  bindings  are  among  the  most  requested  reusable  software  components;  we  plan  to  provide  explanatory  infoima- 
uon,  public-domain  bindings,  and  references  to  commercial  products  which  provide  standard  Ada  bindings. 

We  to  provide  both  government-owned  and  proprietary  cross-domain  components,  but  do  not  plan  to  ^ialize  in  any 
p^ular  applicanon  domam  ourselves.  We  will  leave  domain  specialization  to  other  reuse  libraries  and  wiu  provide  easy 
reference  to  those  libraries  by  implementing  a  “yellow  pages”  directory  which  will  assist  users  in  finding  appropriate  librar¬ 
ies  znd  vendors. 


INFRASTRUCTURE  FOR  AN  INDUSTRY 


•  Distributed  network  of  libraries 

•  Interoperation  among  libraries 

•  Diverse  characteristics 

-  Domain  specialization 

-  User  interfaces 

-  Fee  structures 

•  Mixed  public/private  market: 

-  Products 

-  Search/retrieval  methods 

-  Value-added  services 


I  mentioned  that  ASSET’S  long-term  goal  is  to  catalyze  the  development  of  a  national  indusuy  in  software  components. 

We  think  that  industry  is  developing  anyway  and  it’s  important  to  ensure  that  it  will  deal  with  the  unique  requirements  of 
the  Department  of  Defense.  It  is  inevitable,  for  cultural  reasons,  that  there  will  be  many  reuse  libraries.  So,  the  challenge  is 
to  ensure  that  these  libraries  will  be  able  to  interoperate.  ASSET  is  working  with  other  projects  of  the  STARS  program  to 
obtain  necessary  technology,  like  ALOAF,  and  with  the  Reuse  Library  Interoperability  Group  (RIG)  to  formulate  paoposed 
standards  for  interoperation. 

This  variety  of  libraries  will  offer  a  diverse  set  of  characteristics  to  users  and  we  think  that’s  a  good  thing.  Different  librar¬ 
ies  will  specialize  in  different  appUcadon  domains,  will  provide  user  interfaces  suitable  for  different  users,  and  will  have  fee 
structures  suitable  to  different  kinds  of  businesses. 

We  andcipate  that  the  market  will  be  a  mixed  public^irivaB  market  Some  products  for  example  will  be  public-domain; 
others  will  be  government-owned;  and  others  will  be  offered  for  sale  by  private  entrepreneurs.  We  can  andcipate  that  the 
search  and  retrieval  mechanisms  offered  by  individual  libraries  will  be  supplemented  by  value-added  mechanisms  provided 
for  a  fee  by  private  entrepreneurs.  We  can  also  anucipate  that  pivaie  companies  will  offer  other  value-added  services  like 
consulting  and  systems  integration. 

All  0  these  things  will  happen  anyway.  It  is  ASSET’S  job  to  plan,  taciiiiate.  and  catalyze  so  that  the  needs  of  the  Depart¬ 
ment  jf  Deferrse  are  satisfied  by  this  industry. 
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•  STARS  Program 

-  Technology  source,  e.g.  ALOAF 

•  RIG  -  Reuse  Library  Interoperability  Group 

-  Industry/govemment  consensus  group 

-  Standards  to  facilitate  interoperability 

-  Most  reuse  library  programs  are  participating 

•  CARDS  -  Central  Archive  for  Reusable  Defense  Software 

-  Planned  interoperation  with  ASSET 

-  High-tech,  domain-specific  search/retrieval 

ASSCTAtem/VCt 


( 

Of  course,  ASSET  is  one  task  of  the  DARPA  STA31S  program.  Other  projects  within  STARS  are  important  sources  of 
technology,  e.g.  ALO,\F. 

ASSET  is  a  membw  of  the  Reuse  Library  Interoperability  Group  (RIG).  The  RIG  is  a  voluntary  govenunent/indusuy  con¬ 
sensus  group  which  currently  has  twenty-three  members  including  some  major  corporations,  like  IBM,  some  government 
agencies,  like  NIST,  and  most  of  the  major  reuse  library  programs.  The  RIG’S  mission  is  to  investigate  the  problems  of 
interoperability  among  reuse  libianes  and  to  propose  standards  which  address  those  problems.  These  proposals  will  be  for¬ 
warded  to  standards-making  bodies,  like  ANSL  for  their  action. 

ASSET  is  cooperating  with  the  CARDS  (Central  Archive  for  Reusable  Defense  Software)  program  in  performing  inter¬ 
operability  experiments.  CARDS  is  an  example  of  a  library  will  be  apply  high-technology  search  and  retrieval  techniques 
to  a  specific  application  domain. 


{ 
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RELATIONSHIP  TO  OTHER  EFFORTS 
(CONTINUED) 

•  Cooperation  with: 

-  CLM/RAPID 

-  HPCC 

-  AdaNet 

-  Others 

ASSrr/Ma««/VC9 

In  addition,  ASSET  is  cooperating  with  other  efforu  lilce  DISA’s  CIM/RAPID  library,  the  inter-agency  High  Performance 
Computing  and  Communications  initiative,  NASA’s  AdaNet  library,  and  other  programs. 


ASSET 

WHO  TO  CONTACT 


•  Director:  Dr.  Lawrence  Jacowitz,  IBM 

•  Deputy  Director:  Howard  Berg,  SAIC 

•  Other  key  people: 

-  Jim  Moore,  IBM 

-  Chuck  Lillie,  SAIC 

•  Address: 

ASSET 

2611  Cranberry  Square 
Building  2600,  Suite  2 
Morgantown,  WV  26505 

ASSET/Me««/VC10 


IBM  is  the  prime  contractor  responsible  for  the  ASSET  project  and  SAIC  is  the  major  subcontractor  responsible  for  the  op¬ 
eration  of  the  library.  The  key  people  in  Morgantown  are  Dr.  Lawrence  Jacowiu  of  IBM,  the  Director  of  the  ASSET  li¬ 
brary,  and  Howard  Berg  of  SAIC,  the  Deputy  Director.  Key  people  in  the  Washington,  DC  area  are  Jim  Moore  of  IBM, 
(301)  240-7343,  and  Dr.  Charles  UUie  of  SAIC,  (703)  749-3732. 

The  address  of  the  ASSET  library  is  given  on  the  slide. 
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WHO  TO  CONTACT  (CONT.) 


•  Phone  numbers: 

-  For  humans:  (304)  594-1762 

-  For  modems:  (800)  362-7738 

•  Internet  address:  info@asset.com 


ABCT/S>na^ll 


One  can  contact  the  people  at  ASSET  by  calling  the  number  on  the  slide.  Once  an  account  is  estabUshed.  one  can  yr-ss 

the  services  of  ASSET  by  phoning  the  800  number  given  on  the  slide.  ASSET  personnel  can  also  be  contacted  via  Internet 
at  the  given  address. 


Ill 


2 


CARDS  is  an  Air  Force  sponsored  program  contracted  under  .‘he  auspices  of  STARS.  There  have  been  successes 
with  doraain  specific  reuse  and  architecture-based  oompcnents,  but  it  is  difficult  to  make  this  approach  the  standard 
way  of  doing  business.  The  CARDS  projea  will  address  the  issues  that  must  be  handled  in  order  to  make  domain 
specific  reuse  happen. 
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CARDS 

MISSION 


•  Development  of  a  “Knowledge  Blueprint”  in  support  of  implementing 

domain-specific  reuse  ^ 

•  Expand  and  refine  the  prototype  reuse  environment  for  command 
centers 

•  Help  eliminate  ailtural  barriers  to  reuse  within  the  DoD  community 


CAjaStAnmrmmVCa 


CARDS  is  defining  a  knowledge  blueprint  for  domain  specific  reuse.  CARDS  has  developed  a  simple  model  of  the 
command  and  control  domain  in  order  to  validate  the  domain  reuse  processes.  Some  of  the  processes  that  will  be 
included  are  the  domain  analysis  prcxress,  the  incorporation  of  COTS  software  for  use  in  domain  architecture, 
incorporation  of  reuse  into  the  software  developnnent,  and  the  development  of  tools  to  support  reuse.  The  CARDS 
prpjea  will  d-nrelop  methods  that  will  help  organizations  inoorporate  reuse  and  provide  reuse  incentives.  Reuse  must 
be  integrated  completely  into  the  software  development  lifecycle.  It  is  our  intent  to  look  for  ways  to  eliminate  many 
of  the  barriers  to  reuse  in  DoD:  to  faciliute  reuse  being  treated  as  an  inseparable  aspect  of  the  overall  software 
engineering  process  and  to  provide  recommendations  and  guidance  so  DoD  can  create  incentives  for  reuse. 
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CARDS 

“KNOWLEDGE  BLUEPRINT” 

•  Create,  evaluate  and  refine  the  domain  specific  processes  by  using  a 

prototype  application  domain 

•  Incorporate  current  technology 

•  Use  a  simple  model  of  the  command  and  control  domain 

•  Increase  validation  of  blueprint  with  a  second  domain 

•  Develop  handbooks  for  direction  level  staff,  program  managers,  legal 

contractors,  tool  vendors,  and  system  engineers 

I _ 

The  Knowledge  Blueprint  is  a  flexible  plan  that  will  define  the  domain  specific  reuse  process.  Many  people  within 
the  software  development  reuse  community  have  developed  reuse  processes  for  various  stages  of  the  software 
development  life-cycle.  The  CARDS  projea  will  evaluate  and  refine  already  developed  processes  and  create  new 
processes  where  necessary.  CARDS  work  with  STARS  and  DoD  reuse  efforts.  The  blueprint  will  be  based  on  the 
STARS  Reuse  Concept  of  Operations  and  will  provide  instruction  for  tailoring  other  processes  for  domain  specific 
reuse.  Automation  possibilities  will  be  investigated  for  domain  specific  asset  generation  and  qualification,  asset  usage 
evaluation,  and  ^em  composition. 

The  Blueprint  will  be  addressed  in  a  series  of  handbooks  that  will  explain  and  support  domain  specific  reuse  for 
different  audiences.  These  handbooks  will  form  a  large  pan  of  the  blueprint  for  reuse  being  developed  by  the  DoD. 

A  Direction  Level  Handbook  will  address  domain  specific  reuse  for  individuals  having  responsibility  for  an 
application  domain.  An  Acquisition  Handbook  will  be  targeted  to  DoD  program  managers,  legal  and  contracting 
peisoiueL  Issues  such  as  data  rights,  cost  benefits  of  reuse,  license  agreements,  incentives  and  model  contraa 
wording  will  be  addressed.  Acquisition  and  management  strategies  of  existing  government  and  industry  reuse 
proyams  and  prototypes  will  be  reviewed.  An  Engineer's  Handbook  will  provide  clear  guidance  with  specific  actions 
necessary  to  fully  exploit  the  benefits  of  reuse-based  rapid  prototyping  using  a  domain  specific  library  and  domain 
knowledge.  A  Component  Developer's  and  Tool  Vendor’s  Handbook  will  define  actions  necessary  to  develop 
reusable  assets  and  support  tools. 
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CARDS 

CARDS  COMMAND  CENTER  LIBRARY 


•  Testbed  for  evaluation  of  blueprint 

•  Command  and  Control  Domain  Model  encoded 

•  Populate  library  with  assets  for  prototyping 

•  Develop  and  evaluate  the  domain  specific  usage  and  component  metrics 

•  Limited  early  usage  to  selected  government  organizations 


CAKBSLlirnmnullint 


The  C.4RDS  comnund  center  library  has  been  encoded  with  a  simple  command  and  control  domain  model  done  by 
ESD/AVS  domain  e^rts.  The  librazy  has  been  pc^nlated  with  components  provided  by  ESD/AVS.  CARDS  has 
begun  identifkation  ^  domain  spedEc  usage  and  component  metrics.  libiary  functions  are  based  on  processes 
already  developed  by  other  reuse  libraries.  CARDS  command  center  library  piimaiy  goals  are  to  validate  the 
CARDS  blueprint  (discussed  in  Track  4X  and  thus  fadlitttes  the  introduction  of  Domain-Specific  Reuse  into  other 
organizatiens.  At  the  present  time  only  four  user  sites  will  be  designated  with  two  possible  sites  added  within  the  next 


i 


year. 
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CARDS 


Other  Programs 


This  slide  graphically  illustrates  the  cooperative  work  going  on  between  CARDS,  STARS,  RIG,  Universities,  DSSA 
Prism  and  other  projects  within  the  reuse  development  community.  The  blueprint  will  be  developed  with  cooperation 
of  other  organiraiions.  The  RIG  and  ALOAF  will  support  the  necessary  processes  needed  for  interoperability 
between  libraries.  In  order  to  change  the  cultural  barriers  to  reuse,  education  must  take  place  within  academia. 
CARDS  will  support  the  development  of  reuse  based  software  engineering  curriculums.  Prism  will  be  developing  a 
formal  command  and  control  domain  modd,  defining  requirements  and  developing  components  necessary  for  this 
domain.  CARDS  hopes  to  inteiaa  with  the  Prian  staff  in  order  to  validate  the  domain  model,  requirements, 
components  and  the  necessary  processes. 


117 


CARDS 

CARDS  NETWORK 


OUlDSIArttmmntVaf 


CARDS  will  be  conneaed  to  the  following  sites  via  Internet  Interoperability  with  ASSET  will  continue  to  mature 
over  the  next  year.  A  direa  line  to  ESD/AVS  will  be  activated  by  the  new  year.  The  fourth  user  site  still  needs  to  be 
deiermined. 
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REUSE  PIPELINE 


CONOPS 

Libran-  .Mei.harj<ais 
lnt:roDtr2biiit\' 


Feedback 
Domain  Sped£c 
Processes 


CARDS 


Biueprint 


Iiiterope;a£diiy 


VaiidaboD 

Feedback 


ASSET 


Domain 

Specific 

Libraries 


CAJlDSiAi  m^rnttiVGr 


CARDS  as  pan  of  a  reuse  pipeline  is  illustrated  by  this  slide.  The  STARS  CONOPS  is  the  basis  of  the  reuse 
blueprint  CARDS  is  implemented  using  the  RUF,  one  of  the  libraiy  mechanisms  developed  under  STARS.  CARDS 
will  suppon  and  validate  the  standards  for  interoperability  that  is  produced  by  the  RIG,  a  STARS  initiative  group  and 
ALOAF  by  interoperating  with  the  ASSET  projea.  CARDS  will  provide  back  to  the  STARS  programi;  feedback  on 
the  processes  and  tools  that  arc  used  by  the  C^\RDS  projea.  The  blueprint  will  be  validated  with  a  second  domain. 


CARDS 

formally  encoded  model- generic 

_  COMMAND  AND  CONTROT.  S.AMPLE 


“  lUnstrates  the  high  level  of  abstracUoas  within  a  semantic  nT^ 
C^S  i^rts.  The  components  m  the  instances  shown  on  this  slide  are:  Sybase,  delorem  and  arc  info.  For 
^plt,  Syh^  IS  the  instance  that  meets  the  requirements  for  the  database  manager.  The  database"  manager  is 
necessary  to  the  implementation  of  the  mission  application  portion  of  comnmnd  and  control 


CARDS 

F0RIM4LLY  ENCODED  MODEL- GENERIC 
COMMAND  AND  CONTROL  SAMPLE 


cotoiui— ll've* 


Diustrated  is  a  snapshot  of  the  encoded  command  and  control  domain  model  within  the  RUF.  One  of  the  modules  of 
the  RLF  is  a  Graphical  Browser,  the  nser  interface.  The  Graphical  Browser  builds  a  tree  structure  that  fllnstrates 
some  of  the  relationships  between  the  components  in  the  domain  architecture.  FOp  up  menus  are  used  to  navigate 
the  sti-ucture  and  define  the  relationsh^  and  attributes  of  the  domain  model  components.  The  topography  will 
indicate  to  the  user  their  placement  within  the  domain  structure  at  any  given  time. 


CARDS 

SUMMARY 


•  Prototype  Command  Center  Library  to  support  formation  and 
validation  of  blueprint 

•  STARS  product  usage 

•  Builds  on  STARS  CONOPS  providing  various  user  views 

•  Coordination  with  ASSET 


CAKDSUi^m^nfCie 


In  summaiy,  I  would  like  to  emphasize  the  goals  of  CARDS.  CARDS  primaiy  goal  is  to  develop  and  validate  the 
“knowledge  blueprint"  prototyping  the  command  and  control  domain  and  a  second  domain.  CARDS  will  build  on, 
validate  and  feedback  to  the  process  strengthen  over  the  next  year.  We  alread>’  have  meetings  on  a  regular  with 
the  ASSET  staff.  The  purpose  of  these  meeting  are  to  collaborate  efforts  wherever  possible.  For  instance,  metrics, 
library  policies  and  procedures,  backup  exchange  and  interoperability  arc  some  of  the  current  areas  of  coordination. 
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TR4CK  3  TECHNOLOGY  SUPPORT 


Tliesday  December  3,  1991 

2:00-2:45 

Technology  Support— Vision,  Strategy,  Larry  Frank,  Boeing 
and  Achievements 

2:45-3:15 

Break 

3:15-4:00 

Project  Support  Environment 

Services  Reference  Model 

Dr.  Peter  Feiler,  SEI 

4:00-4  JO 

Break 

4:30-4:45 

STARS  Standards  Portfolio 

Jim  Hamilton,  Boeing 

4:45-5:15 

STARS  Role  in  Standards  Maturation 

Bob  Ekman,  IBM 

8:00-8:45 

SEMATECH:  Software  Methods 
and  Tools  Program 

Jeffrey  Kantor  and  Claude  Baudoin, 

SEMATECH 

8:45-9J0 

Community  Involvement  Working 
Group:  Technology  Support 

STARS  ’91 

TRACK  3  TECHNOLOGY  SUPPORT 

Wednesday  December  4,  1991 

8JO-9;15 

IBM  STARS  SEE  Evolution  Strategy 

Mary  Catherine  Ward,  IBM 

9:15-9:45 

Break 

9:45-IOJO 

Unisys  STARS  SEF  Evolution 
Strategy 

Dr.  Thomas  E.  Shields,  Unisys  Defense 

Systems,  Inc. 

10-30-11:00 

Break 

11:00-11:45 

Boeing  STARS  SEE  Evolution 
Strategy 

John  Neorr,  Boeing 

1:45-2  JO 

Technology  Feedback  Session 

Haru  Poize,",  Unisys  Defense  Systerru,  Inc. 
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SEE  TRACK  INTRODUCTION 


TECHNOLOGY  SUPPORT; 

VISION,  STRATEGY,  AND  ACHIEVEMENTS 


Larry  Frank 
STARS  SEE  Architea 
3  December  1991 
(703)  351-53C7 

frank@stars.  rosslyn.  unisys.com 


VG2  Title:  STARS  Vision/Mission 

In  his  opening  plenaiy  presentation,  John  Foreman  addressed  the  STARS  vision,  mission,  and  strategy  in  accelerating 
the  shift  to  a  megaprogramming  model  of  software  development.  This  presentation  will  describe,  at  a  global  level, 
how  technology  will  be  incorporated  within  a  Software  Engineering  Environment  (SEE)  and  evolved  into  a 
well-integrated,  adaptable,  tailorable  environment  supporting  a  process-driven,  reuse-based  engineering  approach  to 
megaprograraming. 
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TECHNOLOGY  SUPPORT 

OUTLINE 


EFARm- 


•  Megaprogamming  Context 

•  Vision  and  Strategy 

•  Approach 

•  Achievements 


Ttdmtioo  StffotJLffmUVCl 


VG3  Title:  Outline 

In  order  to  understand  the  nature  of  the  requisite  technology  support  for  this  shift  to  a  megaprogramming  parariigm 
we  will  context  megaprogramming  Iqi  comparing  the  envisioned  paradigm  with  current  practices.  A  model  of  how 
SEES  are  evolving  will  be  presented  along  with  a  vision  of  what  is  entailed  b  fostering  this  evolution  and  the  strategy 
for  achieving  it. 

The  high-level  aaivities  refleabg  the  STARS  approach  will  be  discussed  along  with  the  process  of  evolvbg  the  SEE. 
Various  aspects  of  the  SEE  evolution  will  be  explored  and  notable  achievements  discussed. 
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TECHNOLOGY  SUPPORT 

PARADIGM  COMPARISON 

CURRENT  PARADIGM 

ENVISIONED  PARADIGM 

Ad  hoc  (Level  1)  process  maturity 

Defined,  measured,  repeatable 
(Level  3-5)  process  maturity 

Few  valid  quality  indicators 

Quality  metrics  coupled  to  process 

Cost/schedule/predictability 

problems 

Predictive  developm.snt  and  cost 
models 

Progress  indicators  generally  lacking 
and  of  questionable  value 

Process  measurement  and  control 

Poor  communication  in 
geographically  dispersed  project 
teams 

Network  based  collaborative 
development 

Adversarial  environment 

Increased  partnership 

VG4-VG5  Title;  Paradigm  Comparison 

Message:  The  goal  of  the  megaprogramming  software  engineering  approach  is  to  develop  unprecedented  systems 
from  precedented  components  using  defmed,  repeatable,  and  measureable  processes  and  to  be  able  to  predict  the 
cosu  of  the  development 

We  offer  some  insight  into  what  the  characteristics  of  the  megaprogramming  paradigm  is  by  contrasting  and 
comparing  it  with  those  of  the  current  software  engineering  approach.  Any  engineering  or  development  approach  is 
predicated  on  a  development  methodology  and  the  underlying  processes  which  support  it 

The  notion  of  being  process-driven  is  based  on  the  ability  to  manage  development  based  on  well-defined,  repeatable, 
and  measureable  processes  in  contrast  to  trying  to  manage  development  activiues  based  on  an  ad-hoc  approach.  In 
order  to  provide  continuous  quality  improvement  it  is  necessary  to  quantify,  capture,  and  analyre  quality  indicators 
both  in  terms  of  the  product  and  the  processfes)  employed  to  produce  that  product 

Greater  organizational  process  maturity  (as  indicated  by  the  SEI  process  maturity  levels^  embodying  the  above 
principles,  leads  to  the  ability  to  predia  development  costs  earlier  in  the  system  life-cycle,  and  hence,  provides  the 
lead  time  to  'ake  corrective  action. 

In  larx.e  scale,  complex  development  projects,  development  teams  will,  likely,  be  spUt  across  organizational 
boundaries  and  across  geographically  dispersed  sites.  This  further  exacerbates  the  already  diSicult  task  of 
commumcation  among  these  teams.  Existing  processes  will  have  to  evolve  to  enable  the  effeaive  management  and 
control  of  collaborative  efforts.  Tooling  will  also  evolve  to  meet  demands  of  network-based  collaborative 
development. 

Currently,  reuse  of  assets  occur,  primarily,  by  transferring  domain  knowledge  from  one  projea  to  another  in  the 
form  of  the  knowledge  base  represented  by  the  project  engineers  and  developers.  The  envisioned  paradigm  faiu 
forth  the  (re)use  of  domain  architertures,  process  and  other  reusable  assets.  In  particular,  we  would  like  to  be  able  to 
synthesize  larger  and  larger  components  from  precedented  components,  (continued) 
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TECHNOLOGY  SUPPORT 

PARADIGM  COMPARISON 


CURRENT  PARADIGM 

Primarily  re-invention 
(Little,  if  any,  reuse) 

Little  advantage  taken  of  applicaiion 
domain  knowledge  and  experience 

Line  at  a  time 


Few  standard  interfaces 


ENVISIONED  PARADIGM 


Reuse  based 


Domain  specific  architectures, 
process  and  other  assets 


Component  based 


Open  architecture/standards  based 


VG4-VG5  Title:  Paradigm  Comparison  (continued) 

Current  development  is  too  often  based  upon  treating  each  new  development  effort  as  unprecedented.  Algorithms, 
utility  “modules”,  and,  ai  ximts,  specifications  are  reused,  but  on  an  ad-hoc  basis.  Under  the  envisioned  paradigm, 
composition  rules  and  “module”  interface  formalisms  will  be  defmed,  evolved,  and  matured  to  enable  the  synthesis 
of  unprecedented  systems  from  precedented  components. 

Finally,  in  order  to  achieve  the  full  benefits  of  megaprogramming,  increased  partnership  among  users,  developers, 
and  the  government  will  become  necessary.  Inaeased  partnership  between  the  user  community  and  the  developers  is 
becoming  a  reality.  Many  current  development  strategics  are  predicated  upon  it,  when  practiced.  But  many  barriers 
between  the  government  and  system  developers  currently  exist.  In  particular,  current  acquisition  and  procurement 
policies  do  not  provide  the  requisite  incentives  to  the  contractors  (developers)  to  warrant  the  full  emplc^ent  and 
sharing  of  reuse  processes  and  assets  across  projects. 
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TECHNOLOGY  SUPPORT 

VISION 


•  Based  upon  open  architecture  framework 

•  Adaptable  approach  for  incorporating  new  technologies 

•  Packaged  as  an  integrated  Software  Engineering  Environment  (SEE) 

•  Supports  distributed  computing  and  network-based  collaborative 
development 

•  Continuous  improvement  in  portability,  adaptability,  reliability,  and 
scalability 


S^wtlUimMVC* 


Message:  The  SEE  is  the  delivery  vehicle  for  provisioning  services  to  the  systems  builder  and  integrator,  and 
ultimately  to  the  end  user.  The  underiying  framework  serves  as  the  integration  platform  upon  which  tools  are 
deployed  and  integrated  on  a  needs-driven  basis. 

Past  attempts  at  providing  monolithic  environments  that  are  responsive  to  development  needs,  irrespective  of 
application  domain  or  projects  within  domains,  have  not  met  with  great  success.  The  STARS  approach  is  based  upon 
an  open  architecture  framework.  This  f.-araework  consists  of  extensible  core  services  which  utilize  a  set  1“  line  of 
text:  Thames  lOpi  flush  leftof  open  standards  as  aocumcnted  in  the  STARS  Standards  Portfolio  SSP). 

As  tools  are  integrated  into  this  framework-based,  open  architecture  environment  to  meet  the  demands  and  needs  of 
the  development  project,  further  standards  will  be  identified,  as  needed,  within  the  profile  to  accommodate  tool  and 
data  interoperability.  This  open  SEE  architeaure  will  support  a  '^lug  and  pLay^  environment,  easily  adaptable  to  the 
application  domain  and  tailorable  to  the  specific  project  needs. 

It  will  also  enable  continuous  improvement  in  tool  portability  across  platforms  and  environments,  adaptability  of 
tools  to  changing  development  processes  and  needs,  reliability  of  installed  components  and  the  environment  itself, 
and  the  scalability  of  system  components  within  the  environment  reflecting  the  scalabiltity  of  process  formalisms 
supporting  distributed  computing  and  network  collaborative  development. 
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VG7  Title:  SEE  Evolution 

Message;  Framework-based  environments  provide  greater  flexibility  in  the  ability  to  adapt  and  tailor  environments 
to  project  needs.  They  also  provide  the  potential  for  vendors  to  reduce  their  tool  development  costs.  Also,  STARS 
provides  value-added  capabilities  by  way  of  process  and  reuse  mechanisms. 

Current  SEEs  exaa  a  heavy  cost  both  to  the  software  developer  and  the  tool  builder.  To  integrate  N  too's  within  an 
environment  potentially  requires  dealing  with  0(N**2)  interfaces  with  re^jeci  to  information  sharing  between  and 
among  those  N  tools.  By  integrating  these  same  tools  with  the  framework,  and  using  framework  provided  services  as 
well  as  the  repository  services,  the  integration  problem  can  be  reduced  to  dealing  with  0(N)  interfaces.  Thus,  the 
problem  can  be  reduce  by  an  order  of  magnitude  (as  a  function  of  the  number  of  tools  within  the  environment). 

Also,  vendors  currently  provide  (within  each  tool)  many  of  the  selfsame  services  as  are  provided  in  the  framework. 
With  the  advent  of  the  framework-based  environment,  tool  builders  could  take  advantage  of  these  framework 
services  to  obviate  the  necessity  of  developing  and  maintaining  these  services  as  part  of  the  tool  infrastruaure. 

Ultimately,  and  ideally  (from  a  environment  integrator’s  perspective),  we  would  like  to  see  tool  architeaures  that 
provide  visibility  of  functional  interfaces  within  the  tool  (or  tool  suite)  so  that  other  layered  services  or  tools  could 
invoke  that  functionality  while  conforming  to  the  standards  that  infuse  an  open  s>stems  architeaure. 

While  STARS  provides  value-added  capabilities  in  iht  areas  of  reuse  and  process  mechanisms,  the  envisioned 
environment,  instantiated  for  a  given  development  project,  is  guided  by  the  organization’s  business  processes  as  well 
as  the  processes  that  inform  the  development  methodology.  This  is  the  basis  for  wf,ai  is  meant  by  process-drh’en 
development. 
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TECHNOLOGY  SUPPORT 

OBJECTIVES 

•  Demonstrate  the  benefits  of  framework  -  based  approach  to 

instantiation  of  soft>vare  engineering  environments  (SEEs^ 

•  Provide  fTinsition  support  to  reduce  adoption  risks  inherent  in 

integrating  and  utilizing  new  technologies 

•  Ensure  that  the  basic  infrastructure  is  available  to  support 

-  process  management  and  control 

-  reuse  libraries  and  support  mechanisms 

-  tool  interoperability  and  integration 

VG8  Title;  Objeaives 

Message;  In  order  to  realize  the  potential  productivity  increases  that  megaprogri’jnraing  portends,  it  must  be 
technically  feasible,  reduce  overall  life-cycle  development  costs,  and  deliver  quality  systems  in  a  timely  manner 
(bener,  cheaper,  faster). 

Megaprogramming  will  dramatically  impaa  the  way  ^ems  will  be  built.  Tools,  by  themselves,  can  not  provide  the 
needed  produaivity  gains.  The  system  development  methodology  and  associated  processes  and  disciplines  must 
change  to  reflect  the  new  development  paradigm.  Tools,  in  a  real  sense,  reflect  the  autOTCiion  of  these 
(sub)processes. 

As  with  any  fundamental  change  in  the  way  business  is  done,  the  shift  to  a  megaprogiamming  paradigm  will 
encounter  cultural  impediments  within  the  adopting  organization.  To  overcome  these  barriers  and  to  reduce  the 
inherent  risks  to  its  adoption,  STARS  will  demonstrate  the  efficacy  and  efficiency  of  t'’e  framework-based  approach 
on  real  OoD  programs. 

STARS  will  provide  transition  suppon  to  the  seleaed  demonstration  prcjects  to  a' !  project  staff  in  f  .'Uy  exploiting  its 
capabilities  while  rainimizing  the  impacts  of  adoption  within  the  projea  organization  itself. 
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r«'AM0d0p>  support 


VG9  Title;  Acuvities 

Message:  Monolithic  SEEs  fail  to  meet  the  evolvirig  needs  of  the  development  environment.  They  are  difficult  to 
adapt  to  multiple  application  domains  and  to  tailor  to  specific  projea  needs  within  those  domains.  Moreover,  they 
arc  expensive  to  maintain. 

To  fulfill  the  suted  objeaives,  the  STARS  strategy  is:  to  identify  and  build  the  SEE  infrastructure  based  on  an  open 
archiicCTure  frameworfc  to  augment  its  basic  capabilities  by  integrating  tools  within  the  framework-based 
ensironment;  and  to  instantiate  and  deploy  these  SEEs  on  the  selected  demonstration  projects. 


TECHNOLOGY  SUPPORT 

ACmTHES  DETAIL 


Develop  open  architecture  specification 

•  Identify  candidate  industry  standards 

•  Identify  core  service  requirements 

•  Support  open  architecture  working  group 

•  Involve  user  and  vendor  communities 

•  Evolve  specification 

•  Conduct  risk  reduction  prototyping  activities 

•  Develop  top  level  information  model 


VGIO  Title:  Detailed  Activities 

Message:  The  critical  elements  supporting  an  open  architeaurc  specification  are:  identification  of  the  core  services, 
relevant  standards,  and  supporting  information  model. 

STARS  has  defined  the  reqi’Lements  and  criteria  that  charaaerize  the  extensible  set  of  framework  services  with 
input  from  external  workirg  gro .  ps  addressing  simiJar  problems.  These  were  ased  to  identify  candidate  open 
standards  which  were  subseque.itly  profiled  in  the  SSP  (see  Jim  Hamilton’s  and  Bob  EJtman  s  presentations). 

Suice  STAiRS  seeks  to  fully  exploit  ccmmerdal  products  m  the  SEE  build-outs,  the  vendor  community  was  briefed  on  this 
standards  portfoUo  at  the  CASE  Vendors  Workshop  in  July  1991.  The  vendor  community  was  given  the  opportunity  to 
react  to  the  standards  portfolio.  The  reaction  was,  generally,  favorable. 

To  improve  the  usability  of  the  framework-based  SEE,  ST\RS  is  currently  engaged  in  prototyping  tool  portability  and 
tool-to-  framework  integration  and  interoperability.  The  results  of  the  experiments  and  protyping  activities  will  be 
documented  in  reports  and  lessons  learned  documents. 

To  further  improve  tool  and  f.-araework  interoperability,  we  are  working  closely  with  the  prunes’  comraeroal  counterparts 
and  other  interested  parties  to  derive  top  level  information  models  supporting  both  framework  services  and  augmented 
SEE  capabiliiies  as  they  are  integrated  wiinin  the  environmeni. 
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TTCHNOLOGY  SUPPORT 

ACnviTIES  DETAIL 


DARBff 


SEE 

Development 


■  Incrementally  grow  generic  SEE  capability 

•  Experiment  early  with  prototypical  frameworks 

•  Integrate  and  test  COTS  tools 

•  PrototyiJe  reuse,  process,  and  DoD  unique  tools 

•  Customize  framework  for  DoD  use 

•  Tune  SEE  for  performance 

•  Refine  information  model 

•  Support  evolution  of  selected  industry  standards 


VGll  Title:  Detailed  Aaivities 

Message;  Prototyping/experimentation  with  the  integration  of  various  COTS  tools  is  being  carried  out  to  ensure  the 
usability  of  these  environments  on  the  demonstration  projects. 

In  order  that  the  SEEs,  that  the  primes  will  instantiate  for  the  demonstration  projects,  be  usable  on  those  projects, 
prototyping  efforts  are  being  conduced  in  the  areas  of:  tool-to-tool  interoperability,  tool-to-framewrok  integration,  and 
frameworic/SEE  admutisiration. 

COTS  tools  are  being  integrated  within  the  SEEs  to  improve  their  eventual  usability  on  the  demonstrations.  Whatever 
tooU  arc  ii*itanuaied  i;:  use  on  these  projects  will  be  integrated  (to  some  level)  within  these  environments.  The  lessons 
learned  with  these  prototyping  efforts  will  be  documented  and  employed  to  reduce  the  integration  efforts  on  behalf  of  the 
demonstration  projects. 

Also,  reuse  and  process  technologies  developed  on  the  STARS  program  (and  elsewhere)  will  be  integrated,  where  feasible 
and  where  supponed  by  the  business  case,  to  improve  the  usability  and  cffecuvity  of  the  SEEs  deployed  on  the  projects. 

As  additional  func.ionai  capabUuies  and  tools  arc  integrated  within  the  SEE,  the  supporting  informaiion  model  wdl  be 
refined  and  extended.  Moreover,  as  new  tools  arc  integrated,  the  SSP  must  be  augmented  to  address  addiuonal  standards 
necessary  to  maintain  the  openness  of  the  architeaure  and  to  support  tool  interoperabdity  as  wcU  as  the  interoperability 
of  the  information  model,  and  funher.  to  promote  data  sharing  across  iH-  tools  that  will  populate  the  environment.  ' 
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TECHNOLOGY  SUPPORT 

ACnVYUES  DETAIL 


Instantiate  SEEs  for  demonstration  project 

•  Customize  SEE 

-  Interface  to  asset  libraries  application 

-  Adapt  to  selected  domain 

-  Tailor  to  specific  project 

-  Integrate  tools  rs  required 

•  Develop  system  administrator 
concepts/guidelines 

•  Baseline  demo  project  configuration 

•  Develop  SEE  user  training 

•  Train  environment  support  personnel 

•  Train  system  administrator  and  SEE  users 


VG 12  Title;  Detailed  Activities 

Message;  To  promote  usability  of  the  instantiated  SEE  and  improve  its  performance,  the  supporting  prime  will  work 
closely  with  projea  staff  to  customize,  adapt,  and  tailor  the  environment  to  the  project’s  development  environment. 

As  the  projects  are  identified,  the  supporting  prime  will  work  with  the  projects  to  identify  and  integrate  any 
domain-specific,  DoD  specific,  and  project  unique  tools  supporting  the  project’s  development  effort.  The  SEE 
instantiated  for  use  on  the  demonstrations  must  be  customized  with  respea  to  the  tools  integrated  for  use  therein 
and  for  usability  and  pcrfomiance.  The  SEE  will  be  baselined  for  the  selcaed  project  and  projea  staff  will  be  trained 
in  its  administration. 
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TECHNOLOGY  SUPPORT 

STARS  SEE  APPROACH 


Trial 

Point 

c> 

Technology 

Cultural 

o 

Institutional- 

Solutions 

Evolution 

Impact 

ization 

Usage 


•  Framework- 
based  SEE  test¬ 
beds 

•  Prototype 
information 
models 


•  Scalable  open 
architecture 

•  COTS  supplied 
tools 

•  Tool  portability 
experiments  ao-oss 
mulnple  frame¬ 
work-based  SEEs 

•  Evaluate  tool-to- 
lool 

interoperability 

•  Integration  of  pro¬ 
cess  and  reuse 
mechanisms 

•  Explore  frame- 
work-to- frame¬ 
work 

interoperability 


•  Guidelines  and 
techniques  for  ex¬ 
tending  core  services 

•  Guidelines  for  adap- 
ting/tailonng  SEEs 
to  applicaoon  do- 
mains/projects 

•  Identify  and  publicize 
cost  benefits  of  fra¬ 
mework-based  ap¬ 
proach 


•  Successful 
demonstradoa 
of 

framework- 
based  approach 

•  Commercial 
technology  for 
instanbaong  fra¬ 
mework-based 
SEEs 

•  Frameworks  as 
part  of  commer- 
dal  platform 


t'LfimMVCIS 


VG13  Title:  STARS  SEE  Approach 


Message:  The  STARS  SEE  development  approach  is  an  iterative  one  that  seeks  to  evolve  existing  SEE  capabilities 
based  upon  prototyping  and  experimentation.  To  ease  the  cultural  impaas  of  adoption  and  to  reduce  technical  risk, 
ongoing  releases  of  SEE  capabilities  will  be  tested  through  trial  usage  on  internal  projects  and  by  STARS  affiliates. 


Initial  efforts  at  provisioning  framework-based  SEES  have  involved  the  instantiation  of  SEE  testbeds  and  generating 
the  supporting  information  models.  These  will  evolve  over  time  to  form  the  intepmtion  platform  upon  which 
additional  tools  will  be  integrated  to  build  out  the  SEEs  which,  in  turn,  will  be  the  delivery  vehicles  for  supporting 
'Jie  demonstration  projects. 


To  realize  the  benefits  of  the  framework-based  SEE,  it  must  be  adopted  and  used  by  organizations  involved  in 
building  systems  for  both  government  and  industry.  To  ease  the  cultural  impaa  of  adoption  and  to  reduce  the 
associated  technical  risks,  it  is  imperative  that  these  cultural  barriers  be  removed  and  the  attendant  risks  mitigated. 


We  feel  that  this  can  best  be  accomplished  by  demonstrating  the  feasibility  and  utility  of  the  framework-based 
approach  and.  by  inference,  successful  demonstrations  of  development  activities.  To  this  end.  the  SEEs  will  used 
on  real  DoD  projects  as  well  as  uitemal  projects.  Additionally,  we  hope  to  enlist  the  aid  of  affiliates  to  further  test 
theu  efficacy. 


Even  as  these  projects  are  aaively  using  the  SEEs  to  develop  systems,  feedbac<  from  them,  continuing  prime 
activities,  and  from  affiliates  will  be  used  to  refine  and  evolve  the  SEEs  themselves.  We  plan  to  maintain  active 
involvement  of  both  the  framwework  providers  and  the  tool  vendors  to  evoive  and  mature  their  products  to  improve 
SEE  utility  and  (>erformance. 


Guidelines  for  adapting  and  tailoring  SEEs  to  application  domains  and  projects  will  be  documented  along  with 
lessons  learned  and  usage  guidelines.  The  results  of  actual  usage,  as  well  as  attendant  benefits,  will  be  published  and 
disseminated. 

Ultimately,  we  expect  frameworks  tc  be  offered  by  vendors  and  p.oviders  in  much  the  same  fashion  as  graphical  user 
interlaces  are  currently.  That  is,  they  will  become  pan  of  the  commercial  platform  offerings. 
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TECHNOLOGY  SUPPORT 

SEE  EVOLUTION 


1990 


1991 


_L 


1992-93  1993-94 


1995 


ARCHITECT 


•  I  Lessons  Learned 

•  jlninaJ  Requirements 


DEVELOP 
I  and  Instantiate  for 
I  Demonstration 
Projects 

•  plans 

•  Lessons  Learned 
•I  Spedficanons 

•I  Testbed  (SEE(s) 


SUPPORT 
Demonstration ' 
Projects  I 


REFUSE 


Support  Plan 
•  !  Tested  -  SEE(s) 


Proof 

Tested 

SEE(s) 


•  j  Deployed  -  SEE 
Lessons  Learned 


VG14  Tule:  SEE  Evolution 

Message:  The  development  schedule  supports  the  major,  high-level  activities  in  the  SEE  area- 

Early  STARS  foundation  activities  supported  the  technology  eaqjloration  and  definition  of  the  SEE  architecture. 
Requirements  and  oiieria  have  been  defined  for  the  SEE  infrastructure,  the  framework.  The  STARS  SSP 
documents  the  open  standards  supporting  these  framework  services. 

SEE  testbeds  are  currently  being  used  to  prototype  and  experiment  with  tooi  portability,  tool-to-framework 
integration,  and  SEE  support  services.  Experience  obiaincd  therefrom  will  be  used  to  further  refine  and  evolve  the 
SEE  spedficaiions  and  to  provide  feedback  to  the  framework  providers  and  tools  builders. 

Experience  and  lessons  learned  from  the  aforementioned  prototyping  activities  will  be  used  to  instantiate  SEEs  for 
the  demonstration  projects.  The  target  date  is  Oaober,  1993. 

The  SEEs  instantiated  and  deployed  for  use  by  these  demonstration  projects  will  be  adapted  to  the  particular 
application  domain  and  tailored  to  the  demonstration  project  within  that  domain.  Domain  and  DoD  specific  tools  will 
be  integrated  into  these  support  environments  as  well  as  any  project  unique  tooling  that  is  driven  by  speofk  projea 
development  needs. 

Even  as  the  demonstration  projeas  are  utilizing  the  mstantiated  SEEs,  further  efforts  will  be  expended  on  refining 
and  evolvuig  the  framework-based  SEEs.  The  projects  may  clca  to  take  advaniage  of  these  refmement  and 
maturation  efforts  by  updating  their  then  current  baseline  configurations.  Results  of  these  continuing  efforts  will  be 
documented,  published,  and  disseminaied  as  part  of  the  oveiaiJ  STARS  evaluation  efforts. 


TECHNOLOGY  SUPPORT 

SEE  DEVELOPMENT  PROCESS  MODEL 


BARBA: 


rtOmllp 


VG15  Title:  SEE  Development  Process  Model 

Message;  The  SEE  development  process  is  an  iterative  one  designed  to  take  full  advantage  of  evolving  needs  and 
maturing  technologies  as  well  as  efforts  by  groups  outside  of  STARS. 

The  model  presented  represents  a  top  level  view  of  the  species  of  aaivities  that  are  used  by  the  STARS  primes  in 
evolving  the  SEE. 

The  model  provides  for  technology  insertion:  basic  science;  early  technology  efforts  both  endogenous  and  exogenous 
to  DARPA  and  STARS;  and  matuie  technology  from  industry  and  the  oonunerdal  seaor.  Internal  joint  activity 
groups  and  external  working  groups  also  provided  input  to  the  defuiition  of  the  SEE  infrastruaure  in  the  form  of 
requirements,  concepts  of  operation,  and  standards  analysis  efforts. 

The  SEE  Joint  Activity  Group  (SJAG)  has  undertaken  to  define  and  establish  prototyping  plans,  integration 
strategies,  and  tasking  for  evolving  the  SEE  specifications,  the  testbed  SEEs,  and  integration  experiments  within 
those  testbeds.  These  acuvitics,  theu  results,  and  future  plans  will  be  addressed  in  presentations  by  each  of  the 
primes,  entitled  "S'fARS  SEE  Evolution  Strateg)-."  Results  from  the  technology  development,  integratioa  and 
transition  activities  will  be  evaluated  resulting  in  refinement  of  the  SEE  specifications  and  planning  activities. 

The  demonstration  projects  will  also  derive  benefits  from  these  development  and  integration  activities.  Near-term 
products  as  wellas  commercial  products  will  be  used  to  instantiate  SEEs  for  the  demonstration  projects.  Anual  usage 
of  the  SEEs  on  the  projects  will  provide  feedback  to  the  STARS  SEE  evaluation  task,  and  will  be  used  to  refine  and 
evolve  the  SEEs. 

Part  of  the  technology  transition  effort  will  be  ducaed  towards  the  commercialuation  of  the  near-term  STARS  SEE 
products.  The  continuing  evoluuon  of  commercial  technology  and  tools  are  (re)  inserted  into  the  process  via  the 
technology  insertion  subtask. 
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TECHNOLOGY  SUPPORT 

RESULTS  OF  FIRST  ITERATION 


Define  Requirements,  Framework  and 

Architeemres,  and  ^~ents 

Portfolios 

Standards 

Portfolio 

(SSP) 

Host  Meetings 
and  Workshops 

Framework 

Convergence 

Meeting 

CASE 

Vendor's 

Workshop 

Participation  in 
Emerging 

Standards  Efforts 

Next  Generation  Computer  Resources  (NGCR)  /  Projert 

Support  Environment  Standards  Working  Group  (PSESWG) 

National  Institute  of  Standards  and  Technology  (NIST) 

Integrated  Scitware  Engineering  Environment  (ISEE) 

CASE  Integration  Ser/ices  (CIS)  Committee 

Portable  Common  Interface  Set  (PCIS)  Program 

Ada  Semantic  Interface  Specification  (ASIS)  Working  Group 

frriWwtop  Smfpan/LfimJL/yCl* 

VG16  Title:  Results  of  First  Iteration 

Message:  STARS  has  produced  infrastruaure  documents  supporting  the  SEE  development  efforts  and  begun  the 
transitioning  aciiviiies.  STARS  also  actively  supports  similar  efforts  with  external  groups  and  organizations  to  aid  in 
the  two  way  transitioning  of  technology  and  infrastruaure  information. 

STARS  has  been  influenced  by,  and  in  turn,  has  influenced  others  in  the  SEE/fraraework  area.  These  efforts  will  be 
addressed  in  detail  by  Jin.  Hamilton  and  Bob  Ekman  in  their  respective  presenutions,  “STARS  Standards  Portfolio 
(SSP)"  and  “STARS  Role  in  Standards  Maturation.” 
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TECHNOLOGY  SUPPORT 

STARS  ROLES  AND  RELATIONSHIPS 

STARS  Primes  (Boeing,  IBM,  Unisys) 

•  Test  Beds/Open  Archiiecnire  a 

•  Joint  Technical  Development;  Pri'cess  and 

•  DoD-sped6c  Adaputions  /  \ 

Reuse 

/  \ 

•  Individual  Technical  Activities 

/  \ 

•  Technology  transition-demo  of  evohing  capa¬ 
bilities 

Vendor  Communitv  / 

\  Primes  Commercial  Counterparts 

•  Suppliers  of  S/W  engineer- 

(DEC,  IBM,  Unisys) 

ing  tools  populating  SEE 

•  Suppliers  of  tools  and  environments 

Note;  Each  instandaied  SEE  consists  of; 

-  Existing  commercial  capabilities 

-  Third  party  vendor  capabilities 

-  Prime-specific  technical  extensions/adaptations 

•  Supporters  of  STARS  technical  direction 

VG17  Title:  STARS  Roles  and  Relationships 

Message:  STARS  and  the  primes  have  sought  the  active  participation  of  the  primes’  commercial  counterparts  and 
the  greater  vendor  community.  We  think  that  this  participation  is  crudal  to  instantiating  and  deploying  SEEs  on  the 
demonstra'Jon  projects  as  well  as  the  continuing  maintenance  and  support  of  these  SEEs. 

STARS  continues  to  seek  the  active  participation  of  the  primes’  commercial  counterparts  and  the  vendor  community 
in  the  program.  In  July  91,  the  technical  direction  of  the  STARS  program  and  the  STARS  Standards  Portfolio  was 
presented  at  the  CASE  Vendors  Workshop  (CVWS).  Ramdpants  at  the  wor'xshop  were  provided  a  forum  in  which  to 
provide  feedback  to  the  program.  Their  reactions  have  been  noted  and  incorporated  into  infrastructure  documents 
and  piaiuiing  efforts. 

The  commercial  counterparts  have  provided  ongoing  guidance  (sanity  checks)  on  environment  activities  and  have 
indicated  support  of  the  technical  direaions  of  the  STARS  program.  They  underscored  this  support  at  the  CVWS 
and  have  provided  aaWe  support  to  the  SJAG. 

The  primes  continue  to  maintain  responsibUity  for  the  joint  and  prime-specific  technical  activities.  They,  together 
with  the  STARS  program  management  team  have  respoitsibility  for  technology  transition  to  the  commercial  seaor 
and  other  groups,  agenaes,  and  organizations  outside  of  STARS.  STARS  has  also  defined  an  affiliate  program  to 
identify  and  auiveiy  involve  technology  receptors  to  assist  the  program  ui  further  transitioning  activities. 
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VG 18  Title:  SEE  Conceptual  Architeaure 

Message;  The  SEE  conceptual  architeaure  provides  the  context  for  understanding  the  various  functional  capahilities 
required  for  supporting  the  development  environmenu 

A  given  instance  of  a  SEE  dees  NOT  can  NOX  and  will  NOT  support  any  development  projea  irrespective  of  the 
application  domain  and  specific  projea  and  Dod  unique  needs.  A  context  is  needed  for  rationalizing  the  support 
requirements  for  a  development  projea.  The  SEE  conceptual  architeaure  provides  this  context. 

The  model  presented  does  not  represent  any  manifestation  of  a  physical  architeaure,  nor  is  it  complete  with  respea 
to  functional  capabiliues  needed  to  support  the  demonstration  projeas.  It  sho'Jld  be  read  notionally.  It  is  presented 
here  only  to  emphasize  that  the  SEE  is  something  more  than  a  framework,  and  that  there  are  other  common  services 
needed  in  the  environment  supporting  software  engineering  aaivities  in  addition  to  those  offered  by  the  framework. 

Peter  Fciler  in  his  presentaion,  “Projea  Support  Environment  Services  Reference  Model",  will  further  discuss 
additional  environment  services  requisite  to  supporting  software  development. 
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SUi^FOKl 


FURTHER  PROCESS  ITERATIONS 


VG19  Title;  Further  Process  Iterations 

Message:  Further  iterations  of  the  SEE  development  process  will  focus  on  evolving  the  SEE  through  prototyping 
efforts  and  through  usage  of  the  testbeds  in  supporting  internal  projects. 

SEE  testbeds  vill  be  deployed  on  interanl  projects  'viihin  the  primes’  organizations  and  the  results  used  to  evolve 
both  the  SEE  ipedTications  and  the  capabilities  supported  in  the  testbeds.  Reus  and  process  mechanisms  vvill  be 
mtegiaicd  (presentation,  control,  and  data  levels)  within  the  SEE  based  on  need,  usage,  and  expeaed  returns. 
Experiments  will  be  conducted  on  accessing  geographically  dispersed  reuse  hbraries,  and  on  the  exchange  of  reuse 
asseu  across  these  libraries. 

Infoimation  modeling  supporting  deeper  levels  of  integration  and  interoperability  will  be  a  prime  concern. 
Experiments  will  be  conducted  in  extending  the  information  model  s'jpporting  framework  services.  The  commerrial 
partners  have  indicated  interest  in  pursuing  these  efforts  and  propose  to  aaively  become  involved  in  such. 

■^estbeds  will  also  be  deployed  at  each  prime  location  and  the  STARS  Center.  The  latter  will  be  used  to  demonstrate 
the  evolving  SEE  capabilities  to  STARS  affiliates,  venders,  and  other  interested  parties.  These  demonstrations  are 
expeaed  to  commence  Lite  first  quarter.  1992. 
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TECHNOLOGY  SUPPORT 

FRAMEWORK  EVOLUTION 


TOOL  PORTABILITY 

(same  tool,  different  framework) 


TOOL  DATA  EXCHANGE 
(different  tools,  same  framework) 


TOOL  iNTEROPERABIUTY 

(different  tools,  sharing  data  via  framework) 


FRAMEWORK  INTEROPERABILITY 
(different  frameworks  sharing  data) 


Tool  A 


Tool  8 


Tool  0 


Frainework  R  | 


Tool  D 


Framework  S 


VG20  Title:  Frantcwork  Evolution 

Message:  Frameworks  will  continue  to  evolve.  STARS  wiU  maintain  an  active  role  in  furthering  this  evolution. 

Tbol  portability  is  a  chief  concern  of  the  STARS  program.  Some  of  the  proposed  prototyping  efforts  will  address 
portability  issues.  Current  efforts  are  centered  on  tool  integration  and  interoperability.  Each  prime  is  focusing  on 
issues  of  presentation,  control,  and  data  integration,  and  on  the  guidelines  for  integrating  tools  within  their 
respective  environments. 

Further  details  will  be  addressed  ui  the  primes’  presenution  on  “SFE  Evolution  Strategy.” 
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VG21  Title:  Integration  Dimensions 

Message:  Tool  integration  is  a  focus  of  prototyping  activities  by  each  prime.  The  granularity  (coarse  versus  fine)  of 
integration  one  -wshes  to  achieve  across  the  dimensions  of  presentation,  control,  and  dau  has  implications  ft  r  the 
types  of  services  required. 

The  following  are  offered  as  concise  delimtions  of  presenuuon.  control,  and  dau  integration  together  with  what  the 
potential  implications  of  granularity  might  mean: 

Presenution  integration:  the  ability  within  the  environment  to  provide  a  consistent  “look  and  feel”  across  the  tools 
within  the  environment.  The  effea  is  both  visual  as  well  as  behavioural.  At  a  coarse  level,  this  is  constrained  by  the 
man-machine  interface  implemented  within  the  tool  or  tool  suite.  Finer  levels  of  granulanty  necc.isiutes  the 
parametrization  of  the  MMI  aaoss  all  funaional  interfaces  within  the  tool  architeau'c. 

Control  integration:  the  ability  within  the  environment  to  control  initiation,  serialization,  and  synchronizaiion  of 
process  or  task  execution.  It  also  includes  the  notion  of  being  able  to  establish  pre-ambles  and  post-ambles  for 
subproccsses  or  subtasks  and  to  invoke  these  or  other  subprocesses'subtasks  based  on  Lhe  evaluation  of  the 
pre-amble/post-amble.  At  the  coarsest  level,  would  be  the  ability  ‘.o  invoke  a  given  process/task,  a  binary  executable 
for  example.  At  the  finest  level,  it  would  imply  the  ability  to  embed  methods,  triggers,  and  control  points  within  a 
process  network  and  to  subsequently  control  execution  of  subprocesses/subtasks  within  that  network  based  on 
evaluation  of  the  control  structures  (pre-ambles  and  post-ambles,  among  others). 

Dau  integration:  the  ability  within  an  environment  to  share  dau  referenced  via  a  common  represenution  across 
tools,  services,  and  functional  components.  At  the  coarsest  level,  this  would  mclude  the  ability  to  reference  files 
where  the  semantics  of  the  underlying  dau  represenution  lies  within  the  tool  itself.  At  the  finest  level,  it  would 
include  the  ability  to  reference  finer  grained  objects  within  a  defined  class/type  hierarchy  where  the  semantics  of  the 
dau  within  the  hierarchy  is  publicly  available  and  referenced  by  a  common  raeu-model.  (continued) 
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VG21  Title;  Integration  Dimensions  (continued) 

The  primes  will  address  their  strategy  for  integration  of  tools  within  the  SEE  in  their  respective  presentations  on. 
“STARS  SEE  Evolution  Strategy."  Peter  Feiler  in  the  presentation,  “Project  Environment  Services  Refc'ence 
Model"  will  argue  for  a  founh  dimension,  process  integration. 
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TECHNOLOGY  SUPPORT 

ACHIEVEMENTS  CONTEXT 


Bmm 


VG22  Title:  Achievements  Contca 

Message:  STARS  has  various  achievements  to  its  oediu  These  will  be  contexted  in  terms  of  the  characterization  of 
the  STARS  approach. 

The  achievements  of  the  STARS  program  in  the  SEE  area  are  contexted  in  terms  of  the  STARS  SEE  Approach. 
They  wUl  be  charyctenzed  in  terras  of  achievements  that  contribute  to  or  are  manifested  as:  Point  Solutions, 
Technology  Evolution,  Cultural  Impact,  and  Institutionalization. 
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TECHNOLOGY  SUPPORT 

ACHIEVEMENTS 


; Point  ; 

Technology 

Cultural 

k> 

Institutional- 

Solutions 

Evolution 

Impact  I 

ization 

•  Developed  and  distributed  over  50  copies  of  Ada/X-window 
bindings 

•  Universal  Ada  Test  Language  (UATL)  in  use  on  LHX  and 
F-22  programs 

•  Instantiated  three  (3)  SEE  testbeds 


VG23  TiUe:  Achievements—Point  Solutions 

Over  SO  copies  of  the  Ada/X-window  bindings  have  been  delivered  to  various  organizations.  This  effort  has  been 
picked  up  by  conunerdal  companies  and  are  a  basis  for  their  produa  offerings. 

The  Univeisal  Ada  Tbst  Language  (UAJL)  is  in  use  on  the  LHX  and  F-22  programs.  It  promises  to  reduce  the 
development  costs  of  testing  by  30%. 

Each  of  the  three  phmes  (Boeing,  IBM,  and  Unisys)  has  instantiated  SEE  testbeds.  Details  will  be  presented  by  the 
primes’  presenutions  on  “SEE  Evolution  Strategy." 


TECHNOLOGY  SUPPORT 

ACHIEYEMENTS 


TWal 


Point 

Solutions 

o 

Technology 
•  Evolution 

Cultural 

Impact 

Institutional¬ 

ization 

Usage 


•  Documented  STARS  Standards  Profile  (SSP)  and  briefed  it  at 
CASE  Vendors  Workshop  (July  91) 

•  Coordinated  First  Framework  Convergence  Conference  (FRAM 
CON  I)  (January  91) 

•  Continued  liaison  with  external  working  groups,  agencies,  and 
standards  organization 

•  Continued  prototyping  of  alternative  integration/interoperability 
approaches 

-  Tool -to- tool 

-  Tool -to -framework 


VG24  Title:  Achievements— Technology  Evolution 

The  STARS  Standards  Prortfolio  (SSP)  was  briefed  to  the  vendor  community  at  the  CASE  Vendors  Workshop,  July 
1991,  for  their  reaction  and  feedback.  Its  reception  was,  generally,  favorable. 

STARS  coordinated  the  first  framework  convergence  conference  (FRAMCON  I)  which  was  sponsored  by  NIST 
January  1991.  Various  issues  were  identified  and  explored.  Similarities  and  differences  between  ATIS  and  PCTE  were 
noted  and  discussed.  There  seems  to  be  sufficient  interest  in  convening  a  second  framework  convergence  conference 
to  examine  issues  in  greater  detail. 

Bob  Ekman  will  address  the  STARS  continuing  eCforu  with  external  groups,  agencies,  and  standards  organizations. 

As  mentioned  before,  the  STARS  primes  continue  to  prototype  alternative  integration  and  interoperability 
approaches  with  respect  to  tool-to-iool  interoperability  and  tool-to-framework  integration.  Details  will  be  addressed 
in  the  primes’  “SEE  Evolution  Strategy." 


TECHNOLOGY  SUPPORT 

ACHIEVEMENTS 


Point 

Solutions 


Technology 

Evolution 


. .  Cultural . 
'Impact 


Usage 


Institutional- 

iTation 


•  Implemented  nationwide  file  system  (AFS)  network  across  Primes 
and  Government  to  facilitate  network-based  collaborative  program 
activities 

•  STARS  providing  a  ‘^neutral  ground^  to  facilitate  and  catalyze 
technology  exchange 

•  Documenting  guidelines  and  lessons  learned  based  on  prototyping 
activities 

•  Drafted  reuse  and  process  concept  of  operations  (CONOPS)  to  be 
used  along  with  a  SEE  CONOPS  to  refine  and  evolve  SEE  specifi¬ 
cations 

_ _ _ Sm—mtlLfrmt/yC25 


VG25  Title:  Achievements— Cultural  Impaa 

Within  the  STARS  program,  a  nationwide  file  system  (AFS)  has  been  implemented  to  support  the  collaborative 
program  activities.  Several  of  the  STARS  documents  have  been  distributed  via  this  network. 

STARS  »-ill  continue  to  provide  a  “neutral  ground"  to  fadlitate  and  catalyze  technology  exchange.  FRAMCON I  is 
an  example  of  this  activity.  We  are  currently  exploring  other  topics  that  might  lend  themselves  to  this  method  of 
technology  exchange. 

STARS  primes  are  currently  documenting  their  activities,  guidelines,  and  lessons  learned  with  respect  to  their 
prototyping  and  experimental  activities. 

The  Reuse  Joint  Activity  Group  (RJAG)  and  Process  Joint  Activity  Group  (PJAG)  have  drafted  concepu  of 
operations  (CONOPS)  which  will  be  used  as  input,  along  with  the  SEE  concept  of  operations,  to  refine  and  evolve 
the  SEE  specifications. 
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TECHNOLOGY  SUPPORT 

ACHIEVEMENTS 


Point 

Technology 

Cultural  ^ 

Institutional- 

Solutions 

Evolution 

Impact 

^  ization  v 

Usage 


•  Facilitated  STARS  Primes’  commercial  counterparts  (DEC,  IBM, 
Unisys)  technical  direction  and  support  agreement 

•  Sponsored  CASE  Vendor  Workshop  and  will  maintain  liaison 
through  afllliates  program 


VG26  Title:  Achievements— Institutionalization 

^TARS  program  management,  primes’  program  managers,  and  the  STARS  SEE  architea  met  with  the  primes’ 
commercial  counterparts  (DEC.  Nashua;  IBM,  Ibronto;  and  Unisys,  Roseville)  to  the  technical  direction  of 
the  STARS  program.  The  commercial  counterparts  supported  the  technical  directions  and  have  provided  support  to 
the  program.  They  also  participated  in  the  first  framework  convergence  conference,  and  have  indicated  interest  in  a 
proposed  second  conference. 

STARS  sponsored  the  CASE  Vendors  Workshop  (CVWS),  July  1991,  to  present  to  the  vendor  community  the 
program’s  technical  direction  and  to  brief  the  SSR  Case  vendors  have  been  invited  to  STARS  91  to  maintain  curreiKy 
with  the  STARS  program.  Continued  liaison  with  the  vendor  community  will  be  effected  under  the  auspices  of  the 
affiliates  program. 
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VG27  Title:  Summaiy 

Message:  Produaivity  inaeases  are  achievable  through  the  application  of  megaprogiamraing  concepts,  supporting 
processes,  and  reuse  and  SEE  technologies. 

In  order  to  accelerate  the  shift  to  megaprogramraing  and  to  realize  its  potential  benefits  as  applied  to  large-scale, 
ooroplex,  software-intensive  system  development  projects,  it  will  require  thesynergistic  effecu  represented  by  the 
confluence  of  technology  thrusts  in  the  reuse,  process,  and  SEE  areas. 

Megaprogranuning  will  happen  with  or  without  the  STARS  efforts.  The  STARS  role  is  to  accelerate  its  pace.  The 
technology  underlying  and  supporting  this  envisioned  paradigm  is  central  to  proving  the  feasibility  of  the  approach. 
However,  the  crucial  element  in  accelerating  its  pace  is  removal  of  the  cultural  barriers  that  impede  its  acceptance  in 
both  the  government  and  the  industrial  organizations  that  will  be  impacted  by  this  new  way  of  doing  business. 

STARS  can  affea  the  rate  of  acceptance  of  the  megaprogranuning  approach  by  demonstrating  its  eCHency  and 
efTicancy  on  real  DoD  programs,  and  by  working  with  both  the  government  and  industry  sectors  in  improving  the 
panne. 'Ship  needed  to  fully  exploit  its  benefits.  At  the  least,  this  will  require  the  incentivization  of  industry  to:  define, 
evolve,  and  reuse  domain-specific  architectures;  refine  and  evolve  the  processes  supporting  the  megaprogramraing 
approach:  and  incorporate  new/emerging  technologies  in  the  supporting  software  engineenng  environments. 
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Acronym  List 


ABET 

Val  AFS 

ALOAF 

APP 

ASIS 

AITS 

CASE 

as 

conrs 

DARPA 

DCE 

DoD 

ECMA 

FIM 

FJAG 

FRAC 

IM 

IPC 

IRDS 

ISEE 

NGCR 

NIST 

OAF 

OMG 


Ada  Based  Environment  for  Testing 
ATRANSARC  Produ«  (Andrew  File  System) 

Asset  libraiy  Open  Architeaure  Framework 

Application  Portability  Profile 

Ada  Semantic  Interface  Specification 

A  Tool  Integration  Stand^d/ Atherton  Tool  Integration  Standard 

Computer  Aided  Software  Engineering 

CASE  Integration  Services 

Commercial  Off-The-Shelf 

Defense  Advanced  Research  Projects  Agency 

Distributed  Computing  Environment 

Department  of  Defense 

European  Computer  Manufaau''er’s  Association 
Framework  Information  Model 
Framework  Joint  Activity  Group 
Framework  Requirements  and  Criteria 
Information  Model 
Inter-Process  Communication 
Information  Resource  Dictionary  System 
Integrated  Software  Engineering  Environment 
Next  Generation  Computer  Resources 
National  Institute  of  Standards  and  Technology 
Open  Architeaure  Framework 
Objea  Management  Group  (continued) 


31 


OMS 

OSF 

P1175 

PClS 

PCTE 

POCD 

POSEX 

PSESWG 

ROOD 

RPC 

SEE 

SEMATECH 

SIM 

SJAG 

SOCD 

SSP 

UATL 

U1 

UIMS 

XVT 


Object  Management  System 
Open  Software  Foundation 

A  Standard  Reference  Model  for  Computing  System  Tool  Interconnection 

Portable  Common  Interface  Set 

Portable  Common  Tool  Environment 

Process  Operational  Concept  Document 

Portable  Operating  System  Interface 

Project  Support  Environment  Standards  Working  Group 

Reuse  Operational  Concept  Document 

Remote  Procedure  Call 

Software  Engineering  Environment 

A  Consortium 

SEE  Information  Model 

SEE  Joint  Activity  Group 

SEE  Operational  Concept  Document 

STARS  Standards  Profile 

Universal  Ada  Test  Language 

User  Interface 

User  Interface  Management  System 
Extensible  Virtual  Toolkit 
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Project  Support 
Environment  Services 
Reference  Model 


Peter  H.  Feiler 


December  1991 


Software  Engineering  Institute 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213 


Sponsored  by  the  U.S.  Department  of  Defense 


NOTES 


Peter  H.  Feiler 
phf@sei.cmu.edu 
(412)  268-7790 

Acting  program  manager  of  Software  Engineering  Techniques  program 

Project  leader  of  Software  Development  Environments  project 

Alan  Brown  Kurt  Wallnau 
Susan  Dart  Alan  Christie 
Howard  Slomer  (resident  affiliate) 


CASE  Technology  project 
Dennis  Smith  project  leader 
Paul  Zarrella,  Ed  Morris,  Cliff  Huff 


Outline 

Background 

Purpose  of  reference  model 
The  model 
A  PSE  analysis  tool 
Systems  integration  of  PSEs 


NOTES 

For  more  information  about  the  SEl's  work  on  Software  Engineering 
Environments  see  the  information  table  or  several  present  representatives 


PSE  Project  Support  Environment 
SEI  Software  Engineering  Institute 
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Background 


NOTES 


«  Conceptual  work  on  PSE  services  reference  model  at  SEI  in  the  context  of 
environment  work  on  architectures  and  integration  approaches.  Concept 
paper  available  as  SEI  technical  report. 

*  SEI  provides  technical  lead  for  the  NGCR  PSESWG  reference  model  subgroup. 

This  subgroup  will  produce  a  PSE  service  reference  model  report.  NGCR  PSESWG 
contact  is:  Trlda  Obemdorf;  (215/441-2737)  tricia  @NADC.NADC.NAVY.mil. 

See  NGCR  PSESWG  flyer  at  information  table. 

*  SEI  actively  contributes  to  NIST  ISEE  in  both  the  process  management  subgroup 
and  tool  integration  subgroup.  NIST  ISEE  currently  leads  the  international  effort 
of  refining  the  NIST/ECMA  framework  reference  model.  NIST  ISEE  contact  is 
Bill  Wong:  (301/975-3341)  wong@swe.ncsl.nist.gov 

*  SEI  contributes  to  the  coordination  of  these  efforts  as  member  of  their  executive 
committees. 


NIST  National  Institute  of  Standards  and  Technology 
ISEE  Integrated  Software  Engineering  Environments 
ECMA  European  Computer  Manufacturing  Association 
NGCR  Next  Generation  Computer  Resources  effort  by  Navy 
PSESWG  Project  Support  Environment  Standards  workshop  Group 
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Sit 


Er4kiT«»mf  iMttwti 


Characteristics  of  the  Reference 
Model 

Populated  PSEs 
Different  engineering  domains 
Architecture  independence 
Product  independence 


SEE  s  PSE  populated  with  software  engineering 
services 


NOTES 


The  reference  model  covers  a  complete  computer-based  environment,  i.e., 
an  environment  framework  populated  with  tools. 


The  model  accommodates  the  domain  of  Software  Engineering  as  well  as 
other  domains. 


The  term  project  support  refers  to  the  fact  that  the  model  accommodates 
both  engineering  activities  and  management  activities. 

The  model  does  not  impose  a  particular  architecture-in  fact  one  of  its 
purposes  is  to  characterize  different  architectures. 

The  term  service  indicates  that  the  model  does  not  reflect  particular  tool 
products,  but  is  used  to  characterize  them.  One  tool  may  provide  a  number 
of  services. 


SEE  Softw  Engineering  Envi.'onment 
PSE  Projec.  .jpport  Environment 
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PSE  Sn  vices  Reference  Model 

Service  descriptions 
Organization  of  service.^ 

Graphical  depiction  of  P3ESRM 


NOTES 

The  PSESRM  is  not  a  picture, 
it  consists  of 

•  a  set  of  service  descriptions  r  edfied  along  several  dimensions 

•  an  organization  of  these  ser\ .  jes  into  a  stiucture  that  is  characteristic  to 
this  model 

«  a  graphical  depiction  of  this  organization  of  services  for  the 
purpose  of  communication 

Reminder;  The  PSESRM  document  will  be  available  as  a  NGCR  PSESWG 
document  in  1992. 

A  paper  discussing  the  concepts  of  the  PSESRM  and  its  use  will  be 
available  as  an  SEI  technical  report  in  January  1 992. 

Other  papers  on  the  objectives,  goals,  and  strategy  for  PSESWG  are 
available.  See  the  NGCR  PSESWG  flyer. 

NIST/ECMA  framework  reference  model  papers  are  available  from  NIST. 


PSESRM  Project  Support  Environment  Services  Reference  Model 


A  Versatile  PSE  Analysis  Technique 

Description  and  comparison  of  PSE  products 
Comparison  and  selection  of  tool  products 
Characteriration  of  PSE  and  tool  implementations 
Investigation  of  integration  approaches 
Identification  of  PSE  interface  areas 


{ 


The  PSESRM  can  be  used  as  a  basis  for  analysis  of  a  variety  of  aspects  of 
PSEs.  This  presentation  will  highlight  the  use  of  the  PSESRM  as  an 
analysis  technique  for. 


•  describing  desired  populated  PSEs 

•  comparing  populated  PSEs 

•  selecting  tool  to  be  placed  in  a  PSE 

•  describing  both  functionality  and  implementation  of  PSEs  and  tools 

•  determining  ways  to  Integrate  tools 

•  selecting  relevant  interface  standards. 


i 
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Domain  Concepts  and 
Implementation  Mechanisms 


nWM  li  liawr  M  li 


NOTES 

This  illustration  shows  a  separation  of  services  into  those  provided  to  the  end  user 
of  a  populated  PSE  and  those  that  are  available  in  the  infrastructure  to  implement 
the  end  user  services.  This  separation  allows  us  to  examine  PSEs  and  their 
integration  at  the  conceptual  level  of  the  engineering  and  management  domains 
independently  from  integration  at  the  mechanism  level  of  the  implementation. 

Tool  products  can  be  characterized  through  a  combination  of  end  user  and 
infrastructure  services. 

End  user  services  can  be  provided  in  terms  of  framework  services  and  platform 
services,  or  can  interface  directly  with  the  host  or  target  system. 
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NOTES 

The  frameworK  services  represent  those  of  the  NIST/ECMA  reference  model. 
The  framework  services  are  considered  to  be  part  of  a  PSE  product  set.  The 
illustration  shows  service  groups.  Each  service  group  contains  a  number  of 
services  not  shown  here,  but  documented  in  the  NIST/ECMA  framework 
reference  model  report.  The  data  services  (QMS)  are  shown  here  as 
consisting  of  two  subgroups,  object  model  and  object  storage-a  useful 
separation  for  our  analysis. 

The  platform  services  are  expected  to  be  provided  by  the  underlying  computing 
environment.  Their  interfaces  are  relevant,  but  not  necessarily  their 
implementation.  The  platform  services  are  expected  to  correspond  to  POSIX. 

The  host  and  target  system  are  shown  as  two  services.  The  purpose  of  this  is 
to  raise  awareness  of  the  cSstinction  between  the  development  environment 
and  the  application  environment.  Tools  that  are  part  of  a  PSE  may  interface  to 
the  host  environment  via  the  framework  and  platform  services  or  directly 
through  the  host  system  services,  while  potentially  interfadng  to  the  target 
environment  via  a  different  set  of  services. 


QMS  Object  Management  System 

I/O  Input/Output 

Ul  User  Interlace 
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NOTES 

Th«  engineering  services  are  grouped  into  severaJ  (not  necessarily 
exclusive)  engineering  domains.  One  of  the  domains  is  that  of  engineering  a 
populated  PSE,  refen^  to  in  the  figure  as  PSE  construction.  Each  domain 
contains  service  groups  which  are  refined  into  services 

At  this  level  of  the  PSESRM  we  find  (engineering)  domain  specific  concepts 
and  information  models.  For  example,  this  is  where  configuration 
management  concepts  such  as  long  transaction  or  information  models  such 
as  multi'language  symbol  table  formats  can  be  found.  Individual  services  as 
well  as  service  groups  may  have  information  models  associated. 


SE 

EE 

ME 


Software  Engineering 
Electrical  Engineering 
Mechanical  Engineering 


NOTES 


The  complete  PSESRM  Indudes  a  consideration  for  software  processes. 

The  need  for  certain  services  in  a  PPSE  is  determined  by  the  process  it  is 
intended  to  support  Atthough  the  model  accommodates  process, 
computer-based  support  for  process  enactment  is  only  emerging. 

Typically,  only  elements  of  the  process  are  reflected  in  end  user  services  and 
their  infomiation  models. 

STARS  is  investigating  process  centered  SEEs,  which  would  lead  us  to 
PBPPSE(SE)s. 


PPSE  Populated  Project  Support  Environment 

PBPPSE(SE)  Process  Based  Populated  Project  Support  Environment 
for  Software  Engineering 


NOTES 

Ttie  requirements  for  services  to  be  provided  by  a  PPSE  are  determined  by 
the  process  to  be  supported.  This  can  be  illustrated  as  a  view  the  user  of  a 
PPSE  has  of  the  end  user  services  in  the  PSESRM.  This  view  uses  the 
process  level  as  a  filter. 

A  particular  service  may  be  used  in  different  parts  of  the  process. 


NOTES 


The  view  concept  via  the  process  level  can  be  interpreted  in  several  ways: 

•  different  PPSEs  supporting  different  processes  can  be  characterized; 

•  a  particular  PPSE  and  its  end  user  services  can  support  several  process  variants; 

•  different  users  of  a  PPSE  may  have  different  roles,  each  represented  by  a 
different  subprocess.  These  subprocesses  interact  and  make  up  the  complete 
process.  Each  subprocess  acts  as  a  fitter  to  the  subset  of  end  user  services 
appropriate  to  the  role. 


This  service  profile  can  be  used  in  two  ways; 

•  to  determine  service  overlap  between  tools  to  be  combined  in  a  PSE. 
Service  overlaps  may  require  attention,  as  incompatible  concepts  may  be 
supported  or  common  information  models  may  be  maintained 
redundantly. 


to  determine  service  coverage  by  a  given  set  of  tools  in  order  to  satisfy 
the  requirements  of  a  desired  PPSE. 
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NOTES 


Tools  implement  the  end  user  services  they  provide  through  infrastructure 
services.  Some  infrastructure  se»vices  may  be  implemented  by  the  tools 
themselves,  while  others  are  expected  to  be  available  in  the  execution 
environment  of  the  tool. 


The  illustration  snows  one  tool  implementing  its  data  dictionary  through  its  own 
data  base  while  the  other  tool  expects  to  use  a  separate  data  base  product.  At 
the  same  time,  one  tool  implements  its  user  interface  itself  on  top  of  platform 
services,  while  the  other  tool  uses  higher  level  Ul  services,  e.g.,  X-Motif. 

When  examining  these  implementation  profiles,  areas  of  conflict  can  be 
identified,  including: 

•  difference  in  data  (object)  model  used 

•  potential  differences  m  'look  and  feel' 

This  illustration  also  highlights  the  need  for  tools  to  make  interfaces  to 
infrastructure  services  they  implement  publicly  available  in  order  to  encourage 
different  degrees  of  integration  and  interoperation. 


00  Object  Oriented 
ER  Entity  Relationship 
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Requirements  for  Interfaces 

Replacement  of  tools 


Interoperation  between  tool  instances 
Tight  coupling  of  tool  sets 
interchange  between  toots 
Management  and  engineering 
Adaptation  of  PSE  services 


tf 


NOTES 

The  need  for  interfaces  can  be  determined  by  examining  what  can  change  in  a 

PPSE. 

•  Debugger  product  X  can  be  replaced  by  debugger  product  Y. 

•  Two  instances  of  the  same  documentaton  system  product  or  two  different 
documentation  systems  products  need  to  interchange  information 

•  A  design  tool  set  consists  of  edition,  analysis  package,  layout  capability,  and 
code  generator.  These  components  share  information  models  and  concepts. 
Subsets  of  these  may  be  visibie  outside  this  to  cciiection  of  services. 

•  Information  may  have  to  be  transformed  in  order  to  be  mapped  between  the 
information  model  of  a  design  tool  and  a  code  tool. 

•  Management  tools  such  as  metric  collection  tools  are  interested  in  certain 
information  from  a  number  of  engineering  services. 

•  Many  tools  offer  a  layer  which  allows  tailoring  of  the  services.  Examples  are 
user  interface  tailoring  and  user  profiles  for  tools. 
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NOTES 

Data  integration  is  not  a  single  fixpoint.  There  are  degrees  of  integration  and 
interoperation.  Integration  occurs  at  the  level  of  data  storage,  data  model,  and 
information  model. 

Different  tools  with  varying  data  storage,  data  models,  and  information  models  are 
amenable  to  different  integration  approaches.  Each  combination  has  its  own 
cost/benefit  tradeoff. 


SADT  Structured  Analysis  and  Design  Technique 

DBMS  Database  Management  System 
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NOTES 

This  represents  a  view  of  integration  commonly  accepted  by  the  CASE 
industry.  Notice  that  a  particular  integration  approach  typically  does  not  follow 
a  single  dimension. 

It  has  been  recognized  that  a  process  dimension  has  to  be  taken  into  account. 
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Mimjv  cn^wrwi^  insuiuw 

Three  Aspects  of  Integration 


This  slide  illustrates  that  there  are  three  aspects  to  each  of  the  three 
dimensions  of  integration.  Presentation  integration  is  used  as  example. 

The  PSE  end  user  sees  the  system  presented  at  the  process,  end  user 
(concept),  and  infrastructure  (mechanism)  layer.  Typically  user  interface 
services  are  discussed  at  the  mechanism  layer,  e.g.,  much  of  Motifs  "look  and 
feel"  is  related  to  Ul  mechanisms  such  as  menus. 

The  presentation  interface  at  the  end-user  service  layer  addresses  issues  of 
how  to  present  engineering  domain  concepts  consistently.  Similarly,  the 
process  to  be  followed  by  the  user  can  be  presented  in  a  number  of  ways. 


Integration  as  a  Relationship 


process  irrterface 


life  cycle 


Irfe-cycle  steps 


I 

tool  process 


TOOL 

I  tool'tool  control 
I  tooMool  dste 
I  tool-tool  presentation 


Tools  ¥  services 

n  X  n  relations 


tooMramework 

_ i__ 


.  trameYVork  Interface 


NOTES 


Thomas  and  Nejmeh  recognized  that  integration  is  a  relationship  between  two 
entities,  not  a  property  of  a  single  object  (see  SETA2  invited  presentation). 

Taking  process  into  account  as  well,  we  have  tool-process,  tool-tool,  and  tool 
framework  integration.  Tool-process  integration  consists  of  large  grain  (life 
cycle)  and  small  grain  (life  cycle  step)  processes  being  supported  by  tools. 

Two  observations: 

•  Tool-tool  is  a  binary  relationship.  For  n  tools  there  are  nxn  integration 
possibilities. 

•  Tools  are  not  services.  Tools  provide  end-user  services,  but  may  also 
implement  framework  services. 


SETA2  Second  International  Symposium  on  Environments  and  Tools  for  Ada 
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PSE  Interface  Areas 


,  ,  ImBlTwniadow 

*=*  ImariattM 

Proei—  EnlUMT  MraaOueOm  OwMa 

■■r»fen  — ivlp—  C3  Mw<aeM 


Domain  MartaoM  Irnpltmanminn  Martaeo 

loeua  tivetign  pro  earn  toeua  nweugh  laoi  and 

IrOagrodon  aroNtaeturoo 


NOTES 


Tools  are  characterized  by  the  end  user  services  they  provide,  and  the 
infrastructure  services  they  implement  and  use. 

The  process  view  of  end  user  services  reduces  the  number  of  relevant 
tool-tool  interfaces. 

Tools  have  domain  interfaces  at  the  conceptual  level,  and  implementation 
interfaces  to  the  base  computing  environment  (e.g.,  unix)  and  to  the 
integration  vehicle  (e.g.,  a  BMS). 

Tools  have  certain  classes  of  implementation  architectures.  Integration 
approaches  use  certain  infrastructure  services.  This  reduces  the  number  of 
relevant  infrastructure  service  interfaces.  A  particular  tool,  because  of  its 
architecture  and  its  restriction  to  a  certain  integration  paradigm  may  not  need 
to  adhere  to  the  complete  set  of  PSE  infrastojcture  service  interface 
standards. 


BMS  Broadcast  Message  Service 


System  Integration  of  PSEs 


Stfctton 

trwqrKtow 

AdA^MMIOfl 


PtOMU 

npiwiln  ooncapta  >nd  inlofmaUon  fno<Kl« 
tmqtonwnwUoA  maeliaitlMna 


Federated  presentation,  data  and  control 
integration  approach  accommodates 
heterogeneity  and  evolution. 


©  NOTES 

PSEs  are  large  systems  and  have  to  be  treated  from  the  systems 
integration  persp^ve. 

The  three  major  steps  of  PSE  systems  integration  (selection,  integration, 
and  adaptation)  have  to  be  performed  at  ail  three  layers  of  the  PSESRM. 

Since  PSE  technology  will  continue  to  evolve  rapidly,  PSE  architectures 
need  to  accommodate  for  the  evolving  technology,  provide  a  migration 
path,  and  support  heterogeneity  of  technology. 

A  federated  systems  approach  utilizing  a  combination  of  control,  data,  and 
presentation  integration  technologies  that  can  interoperate,  will  be 
demonstrated  by  STARS. 
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STARS  ’91 

STARS  STANDARDS  PORTFOLIO  (SSP) 


Jim  Hamilton 
The  Boeing  Company 
3  December  1991 
(206)  773-3745 
hamilton@stan.boemg.com 


Good  afternoon.  My  name  is  Jim  Hanulion  Grom  the  Boeing  STAJU  Team.  I  will  be  describing  the  STARS  Standards 
Portfolio. 
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STARS  STANDARDS  PORTFOLIO  (SSP) 

STARS  APPROACH  TO  STANDARDS 


DeFine  Requirements, 
Architectures,  and 
Portfolios 

Framework  and 

Environment 

Requirements 

— Standards 

Portfolio 

(SSP) 

Host  Meetings 
and  Workshops 

Framework 

Convergence 

Meeting 

CASE 

Vendor’s 

Workshop 

Participation  i  i 
Emerging 
Standards  Efforts 


N«xt  Gernfation  Computer  Resources  (NGCR)  /  Project 
Support  Environment  Standards  Working  Group  (PSESWG) 


National  Institute  of  Standards  and  Technology  (NIST) 
integrated  Software  Engineering  Environment  (ISEE) 

CASE  Integration  Services  (CiS)  Committee 

Portable  Common  Interface  Set  (PCIS)  Program 

Ada  Semantic  Interface  Specification  (ASIS)  Working  Group 


This  chart  is  a  common  outline  for  my  presenmion  and  the  one  that  follows  (Bob  EJcman  -  'STARS  Role  in  Standards 
Maturation') 

I’m  going  to  talk  about  the  STARS  Standards  Portfolio  -  the  SSP  -  a  list  of  standards  that  STARS  is  committed  ta  1  will 
describe  how  these  standards  are  related  to  STARS  software  engineering  environments.  I  will  present  the  SSP  and  it’s 
evolution,  and  I  will  solicit  your  feedback. 

The  SSP  was  originally  called  the  STARS  Open  Architecture  Framework  (OAF). 
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Standards  are  an  integral  part  of  the  process,  but  not  directly  observed  by  users.  Standards  provide  a  common  point  of 
reference  and  development  They  may  also  act  as  a  filter  for  product  selection.  Consensus  is  the  key  to  the  standards 
process. 

This  is  how  requirements,  standards,  products,  and  users  relate. 

1.  "Requirements"  are  gathered  from  several  places  (RFPs.  NIST.  STARS,  process  technology,  reuse  technology). 

2.  "Products"  are  developed  to  meet  needs  as  expressed  in  requirements. 

3.  "Standards"  are  developed  to  formalize  existing  technology  or  to  push  forward  new  techrologies. 

4.  "Products"  and  "Standards"  do  a  dance  of  new  ideas  and  implementations. 

5.  "U'.  Ts"  use  products  -  not  standards.  They  feedback  their  comments  on  products  to  the  product  developers.  And 
the/  feedback  their  understanding  of  missing  capabilities  to  the  requirement  gathers. 

There  are  essentially  two  paths  to  the  development  of  standards... 

1.  Use  exisung  products  to  establish  a  common  ground  (examples;  IBM  PC.  Adobe  PostScnpt) 

2.  Establish  a  goal  where  no  product  exists  (examples:  Ada.  ECMA  PCTE). 

Both  methods  are  desirable,  but  STARS  will  focus  more  on  the  second  path. 


STARS  STANDARDS  PORTFOLIO  (SSP) 

PURPOSE  OF  THE  SSP 

•  Identify  standards  that  support  software  engineering  environment 
integration 

•  Support  an  analysis  of  standards  to  identify  overlaps  and  holes 

•  Document  a  STARS  consensus 

•  A  filter  for  elements  of  a  STARS  software  engineering  environment 

•  A  reference  point  for  future  work 

SMMi  PMtf 

These  are  the  objectives  for  the  SSP. 

The  SSP  is  needed  by  STARS,  and  useful  for  other  organuaiions. 

POSDC  and  COSIP  is  not  all  you  need  -  you  need  more  software  engineering  domain  specific  standards. 
STARS  is  not  developing  standards. 

You  can  use  the  SSP  today. 
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STARS  STANDARDS  PORTFOLIO  (SSP) 

THE  CURRENT  PORTFOLIO 

In  the  Portfolio 

Under  Consideration 

POSIX.1 

DCE 

X  Window  System 

NFS 

Motif 

VTP 

X.400/XJ00/FTAM 

IRDS 

Telnet/SMTP/FTP 

ASIS 

PCTE 

SPDL 

ATIS 

CGM 

GKS 

PostScript 

PHIGS 

CDIF 

ODA/ODIF 

SGML 

Ada 

The  ponfolio  is  a  mauiring  list  The  uUcs  for  the  columns  arc 
*lri  the  Portfolio”  ^  the  standard  met  all  the  chteria. 

Under  consideration”  *  the  standard  meets  some  of  the  criteria. 


sondaid  -  controlling  organization  -  title 


POSDC.l  -  IEEE  -  Portable  Opcraung  System  Interface 
X  -  MTT  X  Consortium  -  X  W  mdow  System 
Motif  -  OSF  -  Mouf  User  Interface 

FT  AM  -  Cenr  -  OSI  File  Transfer  Access  and  Management 
X.400  -  CClI'f  -  OSI  Message  handling  system 
XJOO  -  CCITT  -  OSI  Network  directory  services 
Telnet  -  DARPA  -  TCPHP  interactive  session  protocol 
SMTP  -  DARPA  -  TCP/IP  Simple  Mad  Transfer  Protocol 
FTP-  DARPA  -  TCP/IP  File  Transfer  Protocol 
PCTE  -  ECMA  -  Portable  Common  Tool  Environment 
ATIS  -  CIS/X3H6  -  A  Tool  Integrauon  Standard 
GKS  -  X3H3  -  Graptucal  Kernel  System 

PHDGS  -  X3H3  -  Programmer's  Hierarchical  Interacuvc  Graphics  System 

ODA/ODIF  -  ISO/IEC  JTCl  -  Open  Document  Architccturc/lnterchiange  Format 

Sevd.  -  ISO/IEC  JTCl  -  Standard  Generalued  Markup  Language 

Ada  -  AJPO  -  Ada  programming  language 

DCE  -  OSF  -  Distributed  Compuung  Environment 

NFS  -  IEEE  -  Network  File  System 

VTP  -  Cull  -  OSI  Virtual  Terminal  Protocol 

IRDS  -  X3H4  -  Information  Resource  Dicuonary  System 

SPDL  -  ISO/IEC  JTCl  -  Standardized  Page  Descnpior  Language 

CGM  -  X3H6  -  Computer  Graphics  Metafile 

PostScript  -  Adobe  -  Page  desenpuon  language 

CDIF  -  EIA  -  CASE  Data  Imerrhange  Format 

ASIS  -  STARS  -  Ada  Semanuc  Imcnace  Specification 
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STARS  ST.4NDARDS  PORTFOLIO  (SSP) 

SELECTION  CRITERIA 


1.  Related  to  software  engineering  environments 

2.  Coverage  of  a  portion  of  the  requirements 

3.  STARS  prime  contractor  concurrence 

4.  Availability  of  conforming  products  within  STARS  timeframe 

5.  Maturity  and  acceptance  of  standard 


These  are  the  criteria  for  selection  of  a  STARS  standard.  The  permit  STARS  to  coordinate  the  assemblage  of  the  STARS 
SEES. 

1.  Softwait  engineering  relevance  -  generally  applicable 

2.  Requirements  coverage  -  this  was  an  engineering  effort 

3.  Commercial  counterpart  concurrence  -  marker  place  dimensioti 

4.  Availabibty  -  this  is  the  pragmatic  niter 

5.  Maturity  -  consideration  of  source  of  standards  -  international,  national,  federal,  de  jure 
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STARS  STANDARDS  PORTFOLIO  (SSP) 

COMPARISON  WITH  OTHER  LISTS 


Framework  Services 

SSP 

MST/APP 

OSF 

Data  Repository 
and  Integration 

PCTE 

ATIS 

IRDS 

SQL 

RDA 

PCTE 

Data  Interchange 

ODA/'ODIF 

SGML 

IGES 

CGM 

ODA/ODIF 

SGML 

STEP 

Operating  System 

POSIX.l 

POSK  (.1/.2/.5) 
GNMP 

OSF/1 

Communications 

X.400/XJ00/FTA.M 

Telnet/S.MTP/FTP 

GOSIP 

TFA(NFS) 

NCS/RPC 

OSF/1 

DCE 

User  Interface 

X  Windows 

Motif 

GKS 

PHIGS 

X  Windows 

XVT 

GKS 

PHIGS 

Motif 

Several  other  orginizaiions  are  developing  lists,  usually  with  different  intents  and  motivation,  but  it  is  interesting  to 
compare.. 


-  Tramewoflc  Services"  are  general  classes  of  retjuirements  -  similar  to  the  "NIST/ECMA  Framewort  Refcrertce 

Model "  sections. 

-  "MST/APP”  is  a  list  from  the  "Nauonal  Institute  of  Standards  and  Technology  (NIST)  /  Application  Portability 

Ptofilc(APP)'. 

-  "OSF"  is  a  list  of  the  Open  Software  Foundation's  products. 


Related  Organiz.'Uions 


AJPO  -  Ada  Joint  Profjam  Office 

ANSI  -  American  Nauonal  Standards  Institute 

CCTTT  -  Consultative  Committee  for  Inicmational  Telephone  and  Telegraph 

GS  -  Case  Iniegrauon  Services  Committee 

DARPA  -  Defense  Advanced  Research  PrT'yrcis  Agency 

ECMA  -  European  Computer  Manulaciurcrs  Association 

ElA  -  Electric  Industries  As.sociauon 

IEEE  -  Insacute  of  Electrical  and  Electronics  Engineen 

ISO/IEC  JTCl  -  International  Standards  Organ izauon/IniemauonaJ  Electrotechnical  Commission  -  Joint  Technical 
Committee 

MTT  -  Massachusetts  Institute  of  Technology 

NIST  -  Nauonal  Insuuite  of  Standards  and  Technology 

OSF  -  Open  Software  Foundation 

X3H3  -  ANSI  Technical  Committee  on  Graphics 

X3K4  -  ANSI  Technical  Committee  on  !RDS 

X3H6  -  A.NSI  fechnicaJ  Committee  on  CASE  Tool  Integration  .ModcU 
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STARS  STANDARDS  PORTFOLIO  (SSP) 

TOOL  WRITER’S  VIEW 


STARS  STANDARDS  PORTFOLIO  (SSP) 

SUMMARY 


•  Version  OJ  available 

•  Use  of  standardized  framework  services  w  ill  require  changes  to 
existing  tools 

•  Continued  focus  on  object  management  system  standards 

•  Planning  evaluation  and  analysis  of  infor-nation  models 

•  VVe  want  your  inputs  to  further  evolve  the  SSP 


summary.  th«  SSP  is  available,  useful,  and  maturing.  We  want  your  participation. 
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STARS  ’91 


STARS  ROLE  IN 
STANDARDS  MATURATION 


Robert  W.  Ekman 
IBM  Federal  Sector  Division 
3  December  1991 
(301)240-6431 

ekmanbtSrckvm  1  .vnet.ibm.com 


Good  afternoon.  My  name  is  Bob  Ekman  from  the  IBM  STARS  Team,  and  1  will  be  covering  the  STARS  role  in  standards 
maturation. 


STARS  ROLE  IN  STANDARDS  MATURATION 

STARS  APPROACH  TO  STANDARDS 


Define  Requirements, 
Architectures,  and 
Portfolios 


Framework  and 

Environment 

Requirements 


Standards 

Portfolio 

(SSP) 


Host  Meetings 
and  Workshops 


Framework 

Convergence 

Meeting 


CASE 

Vendor's 

Workshop 


Participation  in 
Emerging 
Standards  Efforts 


Next  Generation  Computer  Resources  (NGCR)  /  Project 
Support  Environment  Standards  Working  Group  (PSESWG) 


National  Institute  of  Standards  and  Technology  (NIST) 
Integrated  Software  Engineering  Environment  (ISEE) 

CASE  Integration  Services  (CIS)  Committee 

Portable  Common  Interlace  Set  (PClS)  Program 

Ada  Semantic  Interface  Specification  (ASIS)  Working  Group 


This  presentation  will  further  describe  the  STARS  approach  to  standards. 

I  will  continue  the  description  of  of  the  STARS  approach  to  starxlards.  which  was  started  by  Jim  Hamilton  and  his 
explanation  of  the  STARS  Standards  Portfolio  (SSP).  I  will  cover  STARS  hosted  events,  and  how  STARS  has  participated 
in  emerging  standards  efforts. 

You  will  see  how  STARS  influences  the  direction  of  industry  through  outbound  technology  transfer.  And  you  will  see  how 
STARS  benefits  through  inbound  technology  transfer.  This  is  how  STARS  assures  itself  it  is  in-line  with  industry 
direction. 


I 
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STARS  ROLE  IN  STANDARDS  MATURATION 

STARS  AS  A  FACILITATOR 


Lets  us  first  re-look  at  the  role  of  standards  in  improving  software  engineering... 

The  process  of  .standards  maturation  is  a  slow  moving  process.  STARS  is  facilitating  and  accelerating  the  actions  between 
requirements,  products,  siindards,  and  users.  STARS  is  placing  emphasis  on  reference  models,  standards  profiles,  and  Ada 
support  These  actions  have  been  recognized  and  welcomed  by  both  industry  and  the  standards  groups.  The  STARS 
demonstration  projects  are  the  ultimate  wirma  in  this  strategy. 

The  STARS  role  assumes  (or  implies)  certain  responsioilitics  from  the  product  developers 

Framework  provider  responsibilities: 

-  build  to  standards 

-  arcl.itect  frameworks 

-  productize  the  frameworks 

Tool  vendor  responsibilities: 

-  populate  the  SEEs 

-  use  the  starxlardized  frameworks 

-  meet  special  needs 

stars  responsibilities: 

-  provide  a  neutral  temiory  for  tool  vendors,  framework  providers,  and  standards  groups 

-  expenmem  wiih  and  refine  methods  of  framework  integrauon 

-  establish  demonstrauon  projects 
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STARS  ROLE  IN  STANDARDS  MATURATION 

STARS  HOSTED  EVENTS 


•  Framework  Convergence  Meeting 

-  Brought  together  framework  experts  and  providers 

-  Examined  framework  integration  differences 

-  Published  proceedings 

•  CASE  Vendor's  Workshop 

-  Brought  together  CASE  vendors  and  framework  providers 

-  Presented  STARS  Standards  Portfolio 

-  Work  group  sessions  discussed  CASE/F ramework  issues 

-  Distributed  ’’CASE  Vendor’s  Handbook” 

-  Videotape  of  presentations  to  ail  attendees 


STARS  has  taken  an  active  role  in  SEE  technology 
Framework  Convergence  Meeting 

-  Held  January  22-23, 1991  iiNIST  in  Gaithersburg 

-  Participants:  STARS  prime  contractors,  STARS  commercial  counterparts,  PCTE,  ATIS,  and  CAIS  implementators. 

-  explored  and  documented 

—  similarities  arxl  conflicts  of  type  hierarchy  and  data  models 

—  possibilities  of  method  dispatching  for  PCTE 

—  different  strategies  of  versioning  ^  configuration  management 

-  Proceedings  are  published  in  an  IDA  document  (D-972),  available  from  DTIC 
STARS  CASE  Vendors  Workshop  (July  23. 1991) 

-  Held  July  23-24,  1991  in  Seattle 

-  Built  a  market  consensus  for  the  STARS  standards  and  overall  program 

-  Attendance;  1 35  vendors.  DoD  representatives.  STARS  participants 

-  Dataquest  released  a  CASE  tool  market  analysis  -  XASE  Vendor's  Handbook” 

-  Videotaped  the  preseniauons  aiid  distnbuied  to  attendees 
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STARS  ROLE  IN  STANDARDS  MATURATION 

NGCR/PSESWG  PARTICIPATION 


•  Next  Generation  Computer  Resources  (NGCR)  / 

Project  Support  Environment  Standards  Working  Group  (PSESWG) 

-  Establish  a  collection  of  interface  standards  for  Project  Support 
Environments 

-  Provide  guidance  to  DoD  software  engineering  projects 

•  What  STARS  contributed 

-  Chaired  working  groups,  and  participated  in  meetings 

-  Authored  White  Papers,  sections  of  the  Reference  Model,  and  parts 
of  the  Available  Technology  Report 

•  How  STARS  benefited 

-  Provided  a  reference  model  for  SEE  capabilities 

-  A  checkpoint  on  the  STARS  Standards  Portfolio  _ 


NGCR/PSESWG ... 


Sponsor.  Navy 

Membership:  Open,  by  individual 

Meetings:  4  per  year,  last  at  Newport  RI  in  November 

Publicaijons; 

TSE  Reference  Model  While  Paper" 

"Available  Technology  Report 

PSESWG  will  provide  STARS  with  a  SEE  reference  model. 

NGCR  is  looking  for  iri-servicc  sponsorship. 

Near  term  standards  selection  used  the  STARS  Standards  Portfolio  as  one  input. 
PSESWG  is  adopting  the  Teller"  model  for  SEE  services  and  capabilities. 
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STARS  ROLE  IN  STANDARDS  MATURATION 

NIST/ISEE  PARTICIPATION 


•  National  Institute  of  Standards  and  Technology  (NIST)  / 

Integrated  Software  Engineering  Environment  (ISEE) 

-  Define  an  open  system  ISEE  and  identify  tool  interface  standards 

-  Establish  a  consensus  for  US  Government  guidance 

•  What  STARS  contributed  ... 

-  Chaired  working  groups 

-  Authored  sections  of  the  Reference  Model 

-  Participated  in  the  product  mapping  exercise 

•  How  STARS  benefited 

-  Provided  a  reference  model  for  framework  based  SEE  integration 

-  Developed  experience  in  concepts  of  SEE  integration 


NIST/ISEE ... 

Sponsor  NIST 

Membership:  Open,  by  individual 

Meetings:  Twice  per  year,  last  at  Reston  VA  in  November 

Publications; 

"Reference  Model  for  Frameworks  of  Software  Engtnecnng  Envuonments" 
NIST/ISEE  will  provide  STARS  with  a  framework  services  reference  model. 

NIST  is  producing  a  joint  reference  model  with  ECMA/TC33. 

The  ISEE  wwk  is  coordinated  with  NGCR/PSESWG  efforts. 
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STARS  ROLE  IN  STANDARDS  MATURATION 

CIS  PARTICIPATION 


•  CASE  Integration  Services  (CIS)  Committee 

-  Standardize  the  models  of  CASE  tool  integration 

•  What  STARS  contributed  ... 

-  Helped  transform  the  committee  into  an  ANSI  Technical 
Committee  (X3H6) 

-  Supported  the  Demonstration  Working  Group 

•  How  STARS  benefited  ... 

-  Formation  of  a  recognized  standards  body  to  work  on  the  issues  of 
SEE  tool  integration 

-  Models  of  interoperability  between  SEEs 


SmMt  MmbmomQimWVGT 


CIS... 

Sponsor  Vendor  Group 
Membership;  By  Organuauon 
Meetings:  4  per  year 

Publications;  , 

"Project  Proposal  for  the  Development  of  an  American  NauonaJ  Standard  for  CASE  Integration  Services" 
"CASE  Integration  Services  Base  Document" 

CIS  will  provide  STABS  with  models  of  tool  integration. 

CIS  is  looking  at  approaches  to  tool  integration,  with  emphasis  on  object-oriented  approaches. 

The  CIS  base  document  is  derived  from  A  Tool  Integration  Standard  (ATIS). 

Direcuon  is  non-divcrgence  from  PCTE.  and  looking  for  services  from  IRDS. 

X3H6  will  have  initial  meeung  in  January  in  Washington  DC. 
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STARS  ROLE  IN  STANDARDS  MATURATION 

PCIS  PARTICIPATION 


•  Portable  Common  Interface  Set  (PCIS) 

-  Bring  interface  technology  to  the  environment  user 

•  What  STARS  contributed  ... 

-  Environment  experts  to  help  establish  a  consensus 

-  .4uthors  and  reviewers  of  base  line  documents 

•  How  STARS  benefited  ... 

-  Definition  of  SEE  requirements 

-  A  connection  to  NATO  and  international  efforts 


SMMi  .VWneMEbM^Ci 


PCIS ... 

Sponsor  NATO  Special  Working  Group  on  APSE  (AJPO  represents  the  US) 
Membership:  By  AJPO  Invitation 
Meetings:  Ad-hoc 


Publicatiotts: 

"Intemauortal  Requirements  and  Design  Cnieria  (IRAC)" 
"Interface  Technology  Analysis" 

"Requirements  for  the  PCIS  Program" 

PCIS  is  a  source  for  SEE  requirements  for  STARS. 

PCIS  is  pan  of  the  STARS  long  term  strategy. 
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STARS  ROLE  IN  STANDARDS  MATLTiATION 

ASIS  PARTICIPATION 


•  Ada  Semantic  Interface  Specification  (ASIS) 

-  Develop  a  standard  programmatic  interface  to  Ada  compiler 
libraries 

•  What  STARS  contributed  ... 

-  Encouraged  vendors  to  participate 

-  Organized  and  chaired  meetings 

-  Published  the  specification 

•  How  STARS  beneHted  ... 

-  An  agreement  among  Ada  vendors  to  provide  common  interfaces 
into  compiler  libraries 

-  Improved  portability  of  Ada  tools 


ASIS  ... 

Sponsor  STARS 
Membership:  Ada  Vendon 
Meetings  Ad-hoc 
Publications: 

"ASIS.  Version  0.4,  Vendor  Independent  ASIS" 


ASIS  supports  portability  of  Ada  tools. 

There  is  currently  a  buy-in  by  TeleSoft  and  Rational,  with  interest  from  Cadre,  Verdix,  and  others. 
STARS  held  a  BOF  at  the  October  TRI-Ada  Conference. 


STARS  will  continue  to  support  NIST.  NGCR,  CIS,  ASIS,  and  PCIS.  Bui  it  needs  to  be  recognized  that  boti.  STARS  and 
these  organizations  are  nuturing.  STARS  may  be  able  to  relax  its  focus  because  i '  success  in  seeding  these  efforts.  We  are 
able  to  izade-off  doing  standards  work  inside  STARS  because  of  the  cdlection  of  otganizations  that  art  working  on  the 
issues  outside  STARS. 

Information  models,  both  abstract  and  specific  implementations,  are  a  growing  focus  area.  STARS  is  interesting  in 
understanding  the  issues.  We  will  be  working  toward  some  form  of  convergence. 

As  a  fuul  word,  I  would  emphasis  that  participation  in  these  standards  efforts  requires  considerable  effort.  Corporations 
contribute  their  expertise,  the  Government  seeds  and  facilitates  the  eiTons,  and  individuals  professionals  have  supply 
ingenuity  and  personnel  time. 
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STARS  ’91 

IBM  STARS  SEE  EVOLUTION  STRATEGY 


Mary  Catherine  Ward 
IBM  Federal  Sector  Division 
4  December  1991 
(301)240-6135 

wardmc@  rckvm  1  .vnetibm.com 
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This  presentation  describes  the  strategies  of  the  IBM  STARS  Team  for  insiamiating  SEEs  for  use  on  the  STARS 
Demonstration  fmjects.  The  STARS  goal  is  to  evolve  the  SEE  into  a  well-mtegraied,  adaptable,  latlorable  environment 
supporang  a  process-driven,  reuse-based  engineering  approach  to  megaprogramming. 


i 


t 
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IBM  STARS  SEE  EVOLUTION  STRATEGY 

OUTLINE 


•  Context 

•  Overview 

•  Evolution  process 

•  Integration  approach 

•  Process  and  reuse  focus 

•  SEE  evolution  plan 

•  Summary 


SEE  Snuv/MiiflWC: 


This  prescntauon  addresses  the  IBM  STARS  SEE  evolution  strategy  including 

•  the  strategy  for  evolving  to  a  framework-based,  integrated,  COTS  supplied  SEE; 

•  support  for  the  various  levels  of  integration;  presentation,  control  and  data; 

•  integration  of  reuse  library  mechanisms,  and  process  definition  and  management  capabilities;  and 

•  supporting  products,  including  automation  of  methods  and  technologies  for  SEE  usage  including  tool  initgraiion  and 
SEE  system  administxauon  and  managemenL 
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IBM  STARS  SEE  EVOLUTION  STRATEGY 

IBM  STARS  SEE  OVERVIEW 


•  Tailorable  to  a  SEE  Solution 

-  Based  on  project  profile  and  product  maturity 

•  Based  on  IBM  AIX  Technical  CASE 

-  Incorporates  value  add  efforts  from  STARS 

-  Incorporates  project  specific  capabilities 

•  Incremental  insertion  of  presentation,  control,  data  and  process 
integration  capabilities 

•  Focus  on  gaining  real  project  experience  to  evolve  environment 
capabilities 


Pie  IBM  STARS  SEE  is  a  combinaaon  of  hardware  pladorms  and  software  tools  which  support  Ada  software  development 
from  requirements  analysis  through  code  generation,  testing  and  maintenance.  The  SEE  is  adaptable,  i.e..  it  is  tailorable  to  a 
“SEE  solution”  which  meets  the  specific  needs  of  a  project  based  upon  the  project  profile  and  product  maturity  (SEE 
soluuons  are  also  assembled  to  evaluate  solutions  to  particular  problems.). 

THE  IBM  STARS  SEE  is  based  on  IBM’s  AIX  Technical  CASE  Solutions  and  incorporates  value  add  efforts  from  STARS 
(especially  in  the  areas  of  process  and  reuse).  Particular  SEE  soluuons  may  incorporate  project  specific  capabilities. 

To  date,  SEE  solutions  have  been  assembled  from  COTS  products  and  STARS  proioispcs  providing  a  looscly-iniegraicd 
environment.  The  goal  is  to  evolve  the  SEE  solutions  into  framework-based,  integrated.  COTS  supplied  SEE  soluuons. 

The  IBM  STARS  Team  plans  to  support  the  iiKrcmental  inseruon  of  presentation,  control,  data  and  process  integration 
capabiliues  and  their  use  in  assembling  SEE  soluuons.  The  IBM  STARS  Team  places  its  SEE  soluuons  into  active  project 
use  to  identify,  validate  and  retine  environment  capabiliues. 
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Integraung  SEE  soluuons  and  inserting  die  technology  into  real  projects  requires  effort  This  effort  must  be  applied  over 
time  to  take  advantage  of  new  developmenu  and  experiences  gained  through  active  use  of  the  SEE. 

The  IBM  STAJIS  Team  uses  a  concurrent  yet  iteraove  approach  to  evolve  its  environment  capabilities.  It  is  concurrent  in 
the  sense  that  multiple  SEE  solutions  may  be  assembled  and  evaluated  in  parallel.  It  is  iterative  in  the  sense  that  these 
soluuons  evolve  over  time  incorporaung  enhanced  capabilities,  new  technologies  and  user  feedback. 

In  planning,  the  IBM  STARS  Team  outlines  its  objectives  and  evaluation  critena.  A  solution,  (or  multiple  solutions)  is 
assembled  based  on  the  goals  and  objectives.  The  soluuon  also  takes  im.>  xcount  project  needs,  new  technologies,  product 
matuniy,  standards  conformance  etc..,.  The  soluuon  is  demonstrated  and/or  placed  into  active  project  use.  Eeedback  is 
captured  and  the  solution  is  evaluated  against  evaluation  criteria.  The  IBM  STARS  Team  provides  results  to  STARS,  IBM 
commercial.  CASE  vendors  and  other  technology  orgaiuzauons. 

This  approach  (mcluding  the  interim  SLE  solution  and  experience)  will  eiuble  us  to  evolve  today’s  envu-onment  capabilities 
to  a  framework-based  environment  supporting  a  process-dnven.  rcuse-baseo  engineering  approach  to  megaprogramming 
for  the  Demonstrauon  Projects.  We  will  also  use  this  approach  to  assemble  and  evolve  the  Demonstration  Project  SEE 
soluuon. 
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IBM  STARS  SEE  EVOLUTION  STRATEGY 

VIEW  OF  ENVIRONMENT  CAPABILITIES 


•  Are  only  one  piece  of  the  puzzle 

•  Are  identified,  validated  and  refined  through  experience 

-  Real  project  use 

-  Demonstrations 

-  Integration  and  adaptation  efforts 

•  Are  integrated  at  different  levels  and  speed 

•  Evolve  at  different  rates  into  prototypes,  commercial  products  and 
standards 
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The  IBM  STARS  Team  acknowledges  the  following  as  important  obser-ations  and  premises  by  which  we  work; 

•  environment  capabilities  are  the  technology  support  for  the  people  and  the  processes  and  methods  that  they  use  to 
develop  systems: 

•  environment  capabilities  are  identified,  validated  and  refined  through  experience.  This  experience  is  gathered  from 
real  project  use.  demonstrations  and  integrauon  and  adaptation  efforts; 

•  environment  capabiliues  can  be  integrated  at  different  levels  and  sull  be  effecuve.  V»'e  recognize  the  its  possible,  and 
even  desirable  to  have  different  tools  integrated  at  varying  levels;  and 

•  environment  capabilities  evolve  at  different  rates  into  prototypes,  commercial  products,  and  standards.  Gone  are  the 
monolithic  environments  with  all  capabiliues  at  equal  developnient  maturation. 
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This  diagram  depicts  example  elements  from  the  IBM  STARS  SEE.  Note  that  the  circles  represent  integration  frameworks 
and  the  triangles  represent  technology  support  tools.  The  process  and  reuse  support  tools  are  prototypes  developed  by  the 
IB.Vl  S  ■  ARS  Team  and  are  described  below.  The  IBM  STARS  SEE  elements  axe  assembled  to  form  SEE  solutions. 

Cleanroom  Engineering  Process  Assistant  (CEPA)  is  a  prototype  that  automates  a  portion  of  the  Cleanroom  process  which 
allows  engineers  to  follow  the  Cleanroom  process  more  easily  and  effectively.  Cleanroom  uses  a  formal  approach  of 
specifying  a  pipeline  of  small,  user  executable  increments,  utilizing  rigorous  practices  to  create  software  that  is  of  cxtremclv 
hig.i  quality  and  using  siausucal  quality  control  methods  to  ceruly  the  correctness  of  software.  CEPA  was  implemented 
u.‘  ng  KI  Shell,  an  environment  for  implemenung  process  models  as  an  executable  process-driven  application. 

.‘.oftware  Process  .Management  System  (SPMS)  is  a  prototype  tool  set  to  support  software  process  engineering  in  the 
analysis,  modeling,  design,  developn.ent,  evolution  and  support  of  organizational  aixl  project-specific  software  development 
process  mcxlels.  A  process  model  represents  the  generic  sequence  of  tasks,  milestones,  constraints  and  products  necessary  to 
produce  a  specific  type  of  product. 

Asset  .Management  System  (A.MS)  is  an  experimental  reuse  library  mechanism  supporting  librarian  activities,  (lor  example, 
the  definiuon  and  maintenance  of  classificauon  schemes  and  the  cauloging  of  assets)  and  subsenber  acuviues  (for  example, 
searching,  retrieving  and  browsing  assets).  AMS  supports  classificauon  schemes  defined  by  the  IBM/SAlC  Domain 
Analysis  Process  Model,  in  siippon  of  domain-specific  software  reuse.  .^MS  is  designed  ai  run  on  muluple  platiorms  and 
operate  with  other  reuse  library  mechanisms  and  cooperaung  tools  across  a  wide  area  network. 
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IBM  STARS  SEE  EVOLUTION  STRATEGY 

ALPHA  SEE  SOLUTIONS 


•  Real  project  use 

-  Three  Alpha  Test  sites 

•  Demonstrations 


-  STARS  Technology  Center 

-  IBM  Gaithersburg 

-  Conferences  (STARS  ’91,  TRI-  ‘  ‘ 
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In  preparation  for  insianiiating  SEE  solutions  for  the  Demonstration  Projects,  the  IBM  STARS  team  established  an  “alpha 
tesi"  subtask.  The  purpose  of  this  subtask  is  as  follows: 

•  learn  how  to  deal  with  the  cultural  and  technical  barriers  to  transition  to  framework-based  environments 
incorporaung  reuse  and  process  support; 

•  gain  early  experience  and  feedback  in  the  use  of  the  SEE  soluuons; 

•  provide  a  vehicle  for  technology  transfer;  and 

•  be  a  precursor  for  the  STARS  Demonstrabon  Acovity  in  defining  preliminary  project  selection  criteria,  how  to 
support  projects  in  using  and  evaluaung  a  SEE.  and  how  to  capture  information  from  evaluation  projects. 

Currently  we  have  three  active  alpha  test  projects.  These  projects  are  using,  or  are  planning  to  use,  a  wide  range  of  SEE 
tools  and  methods  covenng  the  system  life  cycle.  However,  to  provide  some  focus  lo  the  alpha  test  efforts,  each  project  was 
asked  to  concenuate  on  a  specific  aspect  of  the  lifecycle  (currently  software  design,  requirements  traceability,  reverse 
engineering  and  reusability  ).  The  plan  is  to  inaease  the  scope  of  the  alpha  test  activity  in  1992  by  introducing  frameworks, 
and  process  and  reuse  mechanisms  into  the  alpha  scsi  projects. 

The  alpha  test  projects  provide  us  with  v-aluable  feedback  on  our  alpha  STE  soluuons.  In  addiuon,  the  IBM  STARS  Team 
acuvely  parucipaies  in  conferences  such  as  STARS  ’91  and  TRI-Ada  91  to  demonstrate  our  soluuons  to  a  wider  audience. 
IBM  STABS  SEE  dcmi.nsirauon  siuis  also  include  the  STARS  Technology  Center  and  the  IBM  Gaithersburg  facility. 

The  reader  is  referred  to  CDRL  0'032,  SEE  Technical  Report,  f  r  a  complete  discussion  of  ou  alpha  SEE  solutions,  our 
alpha  wst  projects  and  our  lessons  learned  to  date. 
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IBM  STARS  SEE  EVOLUTION  STRATEGY 

EXAMPLE  SOLUTION 


The  chan  depicts  an  example  of  one  of  our  planned  activities  during  1992.  We  plan  to  migrate  one  of  our  alpha  test 
projects  from  their  loosely-integrated  tool  se<  (represented  by  the  left-hand-side  of  the  picture)  to  a  framework-based 
environment  that  incorporates  reuse  and  process  capabilities  (represented  by  the  right-hand-side  of  the  picuire).  Not  all  of 
the  capabilities  will  be  integrated  at  the  same  level,  and  not  all  of  the  reuse  and  process  capabilities  will  be  exercised.  The 
migration  will  be  scoped  by  a  defined  set  of  goals  and  objectives. 


IBM  STARS  SEE  EVOLUTION  STRATEGY 

INTEGRATION  APPROACH 


Control  Data 


Early 

1992 

-  Assemble  SEE  Solutions 

-  Coarse  Grain 

-  Use  Internal  Developer’s 

Workbench 

-  Based  on  HP  BMS  Technology 

-  Alpha  Test 

-  Experiment  with  PCTE 

-  Coarse  Grain 

-  Use  Enterprise  II 

-  Instantiate  Portion  of  AD/Cycle  IM 

-  Coordinate  with  STARS/Unisys 

Late 

-  Continue  Coarse  Grain  Solutions 

-  Begin  Coarse  Grain  Data  Integration 

1992 

-  Continue  Alpha  Test 

-  Leverage  off  ST.ARS/Unisys 

1993 

-  Enhance  Integration  from  Coarse  Grain  — >  Fine  Grain 

&  on 

-  Focus  on  Demonstration  Project  Capabilities 

The  next  six  chans  outline  the  approach  of  the  IBM  STARS  Team  for  incorporating  control  and  data  integration  capabilities 
and  their  use  in  the  SEE  solutions.  The  IBM  STARS  Team  will  not  actively  focus  on  presentation  integration  issues  aside 
from  the  suppcn  provided  by  the  framework. 

During  early  1992,  the  IBM  STARS  Team  will  assemble  SEE  soluuons  using  coarse  grain  control  integration  capabilities 
based  on  HP  Broadcast  Message  Technology.  HP  Broadcast  Message  Technology  suppons  close  communication  of 
independent  tools,  allowing  the  tools  to  communicate  in  a  networked,  heterogeneous  environment.  Message  requests  allow 
one  tool  to  invoke  the  funcuonality  of  another  tool  and  nouficaiion  messages  allow  tools  lor  the  user)  to  define  triggers  ihai 
respond  to  events  and  iniuatc  other  acuons.  The  IBM  STARS  Team  will  use  an  internal  developers  workbench  prototype  as 
Its  integrauon  framework.  We  will  demonstrate  and  'alpha  test’  the  resulting  SEE  solutions. 

In  parallel,  to  augment  our  pnmary  focus  on  control  integration,  we  plan  to  experiment  with  coarse  gram  data  integrauon 
using  the  Enterprise  II  framework.  Enterprise  II  provides  PCTE  data  integration  services  (currently  at  the  coarse  gram 
level).  We  plan  to  coordinate  our  efforts  with  the  Unisys  STARS  Team  m  the  data  integration  area,  as  their  resources  will 
initially  fexus  on  data  integrauon.  Our  intent  is  to  focus  on  the  mfomiauon  model  and  bnng  our  AD/Cycle  experience  m 
this  area  to  the  STARS  Team. 
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PRESENTATION  TITLE 

DIMENSIONS  OF  INTEGRATION 
EARLY  1992 


This  picture  graphically  represents  the  planned  imegrauon  capabiliucs  of  the  IBM  STARS  SEE  in  early  1992  as  described 
in  the  previous  chare. 

Note  that  the  measure  on  each  axis  is  the  ’granularity’  of  the  data,  control  or  presentation  integration  capabilities. 
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IBM  STARS  SEE  EVOLUTION  STRATEGY 

INTEGRATION  APPROACH 


Control 

-  Assemble  SEE  Solutions 

-  Course  Grain 

-  L'se  Internal  Developer’s 

Workbench 

-  Based  on  HP  BMS  Technology 

-  Alpha  Test 

-  Continue  Coarse  Grain  Solutions 

-  Continue  Alpha  Test 


-  Experiment  with  PCTE 

-  Coarse  Grain 

-  Use  Enterprise  II 

-  Instantiate  Portion  of  AD/Cycle  IM 

-  Coordinate  with  STARS/Unisvs 


-  Begin  Coarse  Grain  Data  Integration 

-  Leverage  off  STARS/Unisys 


-  Enhance  Integration  from  Coarse  Grain  — >  Fine  Grain 

-  Focus  on  Demonstration  Project  Capabilities 
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As  1992  progresses  we  plan  to  continue  our  focus  on  coarse  grain  control  integrauon  and  begin  balancing  this  strategy  with 
more  emphasis  on  providing  and  using  coarse  grain  data  integration  services  in  the  SEE  solutions.  We  plan  to  rely  heavily 
on  the  Unisys  STARS  Team  and  leverage  off  of  their  work  in  this  area. 

Soluuons  assembled  using  both  control  and  data  integration  services  will  be  demonstrated  and  placed  mto  real  projects  for 
acuve  use.  Selection  of  the  underlying  framework(s)  will  be  based  on  availability  and  prior  experience  gained  by  the  IBM 
and  Unisys  STARS  Teams. 
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This  picture  graphically  reprcscnu  the  planned  iniegraiion  capabilities  of  the  IBM  STARS  SEE  in  late  1992  as  described  in 
the  previous  chart 
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IBM  STARS  SEE  EVOLUTION  STRATEGY 

INTEGRATION  APPROACH 


Control 

Data 

Earlv 

1992 

-  Assemble  SEE  Solutions 

-  Coarse  Grain 

-  Use  Internal  Developer’s 

Workbench 

-  Based  on  HP  B.MS  Technology 

-  Alpha  Test 

-  Experiment  with  PCTE 

-  Coarse  Grain 

-  Use  Enterprise  II 

-  Instantiate  Portion  of  AD/'Cycle  IM 

-  Coordinate  with  STARS/Unisys 

Late 

-  Continue  Coarse  Grain  Solutions 

-  Begin  Coarse  Grain  Data  Integration 

1992 

-  Continue  Alpha  Test 

-  Leverage  off  STARS/Unisys 

1993 

-  Enhance  Integration  from  Coarse  Grain  — >  Fine  Grain 

&  on 

-  Focus  on  Demonstration  Project  Capabilities 

SEE  E^aoBoi  SumdAVu^VCII 


Dunng  1993  and  throughout  the  demonstration  time-frame,  the  IBM  STARS  Team  plans  to  enhance  the  capabilities  of  the 
SEE  solutions.  In  panicular  we  plan  to  evolve  from  coarse  grain  control  and  data  integration  to  fine  grain.  Heavy  emphasis 
will  be  placed  on  supporting  the  Demonstration  Project  with  a  tailored,  adaptable  SEE  solution  and  supporting  work  prod¬ 
ucts  such  as  training,  and  iniegrauon  guidelines.  We  will  support,  adapt  and  evolve  the  Demonstration  See  solution  over 
the  lifetime  of  the  demonstration. 
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This  picture  jraphically  represents  the  planned  integration  capabilities  of  the  IBM  STARS  SEE  in  1993  and  beyond  as 
described  in  the  previous  chan. 
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IBM  STARS  SEE  EVOLUTION  STRATEGY 

PROCESS  AND  REUSE  FOCUS 


•  Processes 

-  Cleanroom  Engineering 

-  Software-First  Life  Cycle 

-  Domain  Analysis  Process  Model 

-  Reuse  Library  Operation  Process  Model 

-  Asset  Certification  Process  Model 

•  Reuse  Concept  of  Operations,  Process  Concept  of  Operations 

-  Identifies  processes 

-  Outlines  how  they  fit  into  different  lifecycles 

•  Standards 

-  ALOAF  -  Asset  Library  Open  Architecture  Framework 


The  next  (wo  chans  highlight  the  IBM  STARS  Team  effons  in  the  process  and  reuse  areas  in  preparation  for  the 

Demonstration  Projects.  The  first  chan  focuses  on  our  efforts  in  identifying  and  defining  processes  and  standards.  The 

second  chan  outlines  process  and  reuse  mechanisms  identified  for  incorporation  into  the  IBM  STARS  SEE  solutions  and  ' 

further  evolution  of  their  capabilities. 

The  joint  activity  groups  (one  member  from  each  STARS  prime,  a  STARS  prime  system  architect  and  other  members)  for 
process  and  reuse  focus  heavily  on  identifying  and  defining  the  processes  to  suppon  megaprogramming.  Key  processes 
developed  or  in  development  by  the  IBM  STARS  Team  include: 

•  Geanroom  Engineering  Process  -  process  for  creating  software  that  is  of  extremely  high  quality  and  uses  statistical 
quality  control  methods  to  certify  the  correctness  of  the  software. 

•  IBM  STARS  Team  Software-First  Life  Cycle  -  An  IB.M  STARS  Team  instantiauon  of  the  class  of  life  cycles 
known  as  Software-First  Life  Cycles. 

•  Domain  Analysis  Process  Model  -  process  for  developing  generic  models  and  architectures  that  suppon  multiple  (. 

products  across  and  applicauon  domain. 

•  Reuse  Library  Operauon  5*roccss  .Model  -  process  for  operaung  an  asset  management  system. 

•  A.sset  Cemficauon  Process  Model  -  process  for  cerufymg  assets  in  an  asset  management  system. 

Another  important  effort  by  these  groups  is  the  parucipauon  in  defining  an  Asset  Library  Open  Architecture  Framework 
(AI-OAF).  The  goal  is  to  ensure  seamless  interoperablity  between  different  reuse  libranes  on  different  platforms  with 
possibly  different  data  models. 
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IBM  STARS  SEE  EVOLUTION  STRATEGY 


PROCESS  AND  REUSE  FOCUS  (CONT.) 


•  Process  Support 

-  Project  planiiing,  process  enactment,  role  based  process  modeling, 
etc. 

-  CandidaVi  tools 

-  KI  Shell,  SPMS,  Microplanner 

•  Asset  Management  Support 

-  Classification  scheme  definition,  cataloguing  of  assets,  search  for 
assets,  etc... 

-  Asset  Management  System 

-  ALOAF  compliant  server 

-  Subscriber,  librarian  clients 


To  provide  process  capabilities  in  a  SEE,  one  rnust  provide  support  for  process  activities  such  as  project  planning,  process 
enactment  and  role-based  process  modeling.  The  IBM  STARS  Team  has  identiHed  a  suite  of  candidate  tools  which  cover 
the  wide-range  of  process  activities.  Currently  these  tools  arc  loosely  integrated,  but  plans  exist  to  evolve  the  tool 
capabilities  and  integration  levels  for  better  process  support  in  the  SEE  solutions.  The  reader  is  referred  to  CDRL  item 
03705,  Software  Process  Tools  and  Techniques  Evaluation  Report,  for  a  complete  discussion  of  the  IBM  STARS  Team 
process  capabilities  and  plans. 

To  provide  asset  management  capabilities  in  a  SEE,  one  must  provide  support  for  asset  management  activities  such  as 
classificauon  scheme  dcfiniuon,  asset  cataloging,  and  searching.  The  IB.M  STARS  Team  has  developed  a  prototype  called 
Asset  Management  System  (described  previously)  to  provide  asset  management  suppon  m  the  SEE  solutions.  AMS  will 
have  an  ALOaF  compliant  server  and  we  plan  to  develop  subscriber  and  librarian  clients  that  use  the  server.  Currently, 
AMS  is  in  prototype  form  but  SAIC  and  SPS  have  recently  announced  their  intent  to  commercialize  iL  AMS  will  evolve  to 
suppon  enhanced  data  and  control  integration  capabilities  to  suppon  asset  management  m  the  SEE  solutions. 


IBM  STARS  SEE  EVOLUTION  STRATEGY 

SEE  EVOLUTION  PLAN 


7/92 

1/93 

-  Coarse  Grain  Control 

-  Coarse  Grain  Data 

SEE  Solutions 

SEE  Solutions 

-  AMS  Server  & 

-  AMS  Subscriber 

Librarian  Client 

Client 

-  Loosely  Integrated 

-  Coarse  Grain  Control 

Process  Support 

&  Data  Integration 

-  Lessons  Learned 

of  Process  Components 

-  Cultural 

-  Lessons  Learned 
-  Cultural 

-  Integration 

-  Technologies 

-  Integration 

—  Technologies  see  £«*■«• 

o  T7>e  n«xi  two  chans  recap  (he  IBM  STARS  SEE  evolauon  strategy  and  depict  the  expected  products  and  major  milestones. 
By  7/92  we  expect  to  be  able  to  demonstrate  SEE  solutions  based  on  control  integration  capabilities  and  by  1/93  we  expect 
to  expand  the  integration  capabilities  to  include  coarse  grain  data  integration.  We  expect  the  AMS  Server  and  initial 
Librarian  Client  to  be  completed  by  7/93  and  the  Subscriber  Client  shortly  thereafter.  By  7/92  we  will  still  have  a  loosely 
integrated  process  tool  suite,  but  (his  tool  suite  will  be  upgraded  with  both  coarse  grain  control  and  data  integration 
capabilities  for  incorporation  into  (he  SEE  solutions  by  1/93.  Both  the  reuse  and  process  capabilities  will  be  placed  in 
actual  project  use  as  soon  as  possible.  We  expect  to  gain  lessons  learned  on  cultural  impacts,  integration  issues  and  new 
'xchnologies. 
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IBM  STARS  SEE  EVOLUTION  STRATEGY 

SEE  EVOLUTION  PLAN  (CONT.) 


A  "  . . .  '  I  A*  .  ■  A  ' 

7/93  10/93  1994  1995 


—  Fine  Crain  Control  -  Demonstration  _  Refine  Demonstration 
&  Data  SEE  Projects  Project  SEE  Solutions 

Solutions 


-  Tailoring  of 

Demonstration 
Project  SEE 
Solution 

-  Lessons  Learned 

-  Cultural 

-  Integration 

-  Technologies 


-  Incorporate  advances 
&  new  technologies 

-  Lessons  Learned 

-  Cultural 

-  Integration 

-  Technologies 


SE£  Sumc^/Wai^CII 


10/93  marks  the  onset  of  the  Dcmonstiaiion  Projects.  We  e»oect  to  work  with  them  prior  to  this  date  to  set  goals,  and 
objecuv-s,  understand  and  influence  their  processes,  and  tc  *in  SEE  soluuon  tailonng  and  training.  We  will  support  the 
Demonstration  Project,  and  adapt  and  evolve  ihctr  SEE  soluuon  throughout  the  demonstration  time  frame.  We  w  ill 
continue  to  focus  on  capturing  lessons  learned  and  developing  support  products  such  as  integration  guidelines  for  use  by 
others  w  ho  plan  to  transition  to  Megaprogiamming. 
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IBM  ST.^RS  SEE  EVOLUTION  STR.VTEGY 

SUMMARY 

•  IBM  ST.A.RS  SEE  is  tailorable  to  SEE  solution 

•  Integration  evolution  strategy 

-  Coarse  grain  control  -  B.MS 

-  Coarse  grain  data  -  PCTE 

-  Fine  grain  control  and  data 

-  Presentation  integration  technology  from  IBM  AIX  CASE 

-  Process  integration  through  mechanisms  and  framework  services 

•  Leverage  off  Unisvs  ST.ARS 

•  Test  on  real  projects 

S 

££  EvciiAiOt  S(mc|3rAk’«f4/VCl9 

In  siunnw),  ihe  IBM  STARS  Team  plans  to  incrementally  insen  and  use  presentation,  process,  control  and  data 
integrauon  capabiliues  in  our  SEE  solutions,  advancing  from  coarse  grain  to  fine  gram  support  a.;d  use.  The  IB.Vl  STARS 
Team  and  the  Unisys  STARS  Team  evolution  strategies  complement  each  other  and  we  plan  to  leverage  off  each  other’s 
e.xpeiience. 

The  IB.Vl  STARS  SEE  solutions  will  be  placed  in  active  projects  to  obtain  feedback  and  experience  on  the  cultural  and 
technological  obstacles  in  iransitionmg  to  a  framework-based  envurnmeni  supporting  a  process-driven,  reuse-based 
engineering  approach  to  mecaprogramming. 
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This  diagram  maps  ihe  planned  IBM  STARS  SEE  iniegration  services  against  the  NIST  Reference  Model.  The  plans  are  ^ 

for  the  IBM  STARS  SEE  to  use  PCTE  for  data  iniegration,  BMS  for  control  integration  and  OSF  Mouf  or  its  successor 
for  presentation  integration. 
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IBM  STARS  SEE  EVOLUTION  STRATEGY 

STARS  ’91 

•  Prototype  demonstrations 

-  Cleanroom  Engineering  Process  Assistant  (STARS) 

-  Software  Process  Management  System  (STARS) 

-  Asset  Management  System  (STARS) 

-  Developer  Workbench  (IBM) 

S££  EwittacA  Su«icf>Ah'u^V‘CSl 

o  ■Hie  IBM  stars  Team  and  the  IBS!  Corporation  exhitits  at  STAR  ’91  will  include  demonstrations  of  the  follow  ing 

prototspes;  the  Clearmxsm  Engineenng  Process  Assistant  (CEPA),  the  Software  Process  Management  System  (SPMS) ,  the 
.Asset  Sfaj-agement  System  (A.MS)  and  the  Developer  Workbench.  CEPA.  SPMS  and  AMS  have  been  previously  described. 
The  Developer  Workbench  is  a  technology  demonstration  of  an  internal  development  workbench  that  uses  BMS  technology 
for  control  integration  of  developer's  tools  irKluding  editing  and  configuration  management  capabilities. 
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ACRONYMS 


AIX  Advanced  Inieractive  Execum.* 

AMS  Asset  Management  System 

BMS  Broadcast  Message  Server 

CASE  Computer  Aided  Software  Engineering 

CEPA  Cleanroom  Engineering  Process  .Assistant 

HP  Hewlett  Packard 

IBM  International  Business  Machines  Corporation 

IM  Information  Model 

NIST  National  Institute  of  Standards  and  Technology 

PCTE  Portable  Common  Tool  Environment 

SAIC  Science  Applicauons  International  Corporation 

SEE  Software  Engineenng  Environment 

SPMS  Software  Process  Management  System 

SPS  Software  Productivity  Solutions,  Inc. 

STARS  Software  Technology  for  Adaptable,  Reliable  Systems 

UI  User  Interface 


Product  trademarks  referred  to  in  this  presentation. 

Adjgcn  is  a  trademark  of  Mark  V 

AIX  is  trademark  of  the  IBM  Corporation 

Interleaf  is  a  trademark  of  Interleaf 

.KI  Shell  IS  a  tradema'-k  of  Universal  Energy  Systems 

Microplanner  Xpert  is  .1  trademark  of  Micro  Planning  Inc. 

OSFAIouf  IS  a  trademark  of  the  Open  Systems  Foundauon 

Rational  is  a  trademark  of  Rauonal 

Teamwork  is  a  trademark  of  Cadre  Technologies 

WordPerfect  is  a  trademark  of  WordPerfect  Corporat’on 


96 


STARS  ’91 

UNISYS  STARS  SEE  EVOLUTION  STRATEGY 


Dr.  Thomas  £.  Shields 
Unisys  Defense  Systems,  Inc. 

4  December  1991 
(703)  620-7028 

shieIds@stars.resion.unisys.com 

Umjyt  STAJtS  VCl 


'i  his  presentation  describes  the  strategy  of  the  Unisys  STARS  team  for  instaaitiating  a  SEE  for  use  on  one  of  the 
STARS  demonstration  projeas.  The  STARS  goal  is  to  evolve  the  SEE  into  a  well-integrated,  adaptable,  tailorablc 
environment  supporting  a  process-driven,  reuse-based  engineering  approach  to  Megaprogramming. 


UNISYS  STARS  SEE  EVOLUTION  STRATEGY 

OUTLINE 


•  Context 

•  Overview 

•  Evolution  process 

•  Integration  approach 

•  Relationship  to  process  and  reuse  focus 

•  SEE  capability  plan 

•  Summary 


(/•WN  sTA/ts 


The  goal  of  the  STARS  Software  Engineering  Environment  (SEE)  evolution  strategy  is  to  demonstrate  the  benefits 
of  a  shift  from  point-to-point  links  betwten  standalone  tools  to  an  open  architecture  approach  based  on  an 
integrating  framework.  A  STARS  SEE  incorporates  reuse  library  technolo©'  tightly  coupled  with  software 
development  tools  through  use  of  this  integrating  framework,  and  it  provides  process  integration  through  framework 
services  that  allow  the  environment  to  explicitly  support  project-specific  software  development  life-cycle  procedures 
and  methodologies.  In  particular,  a  STARS  SEE  supports  domain  specific  reuse-based  software  development 
processes. 
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••Control  integration"  refers  to  the  ability  to  transfer  conucl  among  a  set  of  aaivities  in  a  seamless,  transparent 
manner.  Examples  of  control  integration  mechanisms  include  shell  scripts,  remote  execution,  remote  procedure  calls 
(RPCX  point-to-point  messages,  and  broadcast  messages.  This  dimension  spans  coarse-grained  composition  of  tools 
into  tool  ensembles  at  the  environment  level  to  fme-grained  composition  of  tool  fragments  into  tools  at  the  tool 
level. 

•'Data  integration"  rtfeis  to  the  ability  to  use  common  t.,.ta  formats  permitting  a  tool  to  easily  use  the  results 
produced  by  other  tools.  Examples  of  data  integration  mechanisms  include  Object  Management  Services  (OMS), 
common  data  schemas,  and  tool  interconnection  languages.  This  dimension  spans  management  of  coarse-grained 
dau  (file-sized  objects)  at  the  environment  level  to  management  of  fine-grained  data  (byte-sized  objects)  at  the  tool 
level. 

••Prescpiation  integration”  refers  to  the  ability  for  tools  to  provide  a  consistent  (visual  and  behavioral)  interface  to 
the  user.  This  is  also  referred  to  as  ••common  look-and-fecl”. 
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UNISYS  STARS  SEE  E\'OLLTIO'  GY 

OVERVIEW 


•  “Trial-by-fire”  den  onstration  of  transition  to  framework-based  SEE 

•  COTS  PCTE-based  framework  technology 

-  Entitj-relation-attribute  (ERA)  based  Information  Model  (IM) 

•  Reuse  libra.7  technology  integrated  with  other  tools 

•  Process  raanagcnent  technology 

•  Technology  and  experience  from  internal  alpha  project  transitioned  to 
STARS  demonstration  project 


Uvqi  S££:SJ>mU„  I'd 


The  Unisys  STARS  approach  is  to  gain  experience  with  the  application  <A  SEE  framework  technology  on  relatively 
controlled,  but  realistic,  alpha  projcas,  and  then  transition  that  experience,  along  with  proven  framework  technology, 
to  one  of  the  STARS  sponsored  demonstration  projects  beginning  Li  Oaober  1993.  Tne  plan  is  to  incrementally 
insert  commercially  available  data  and  control  (and  to  a  lesser  ettent,  presentation)  integration  technology  into  active 
internal  alpha  projects  within  Unisys  Defense  Systems. 

Unisys  Defense  Systems  has  standardized  on  a  loosely  coupled  set  of  software  development  tools.  This  baseline  will 
be  transitioned  to  a  framework-based  SEE  using  the  s?:ne  (and  similar)  tools,  integrated  with  reuse  and  process 
management  lechnolog;/.  The  lessons  learned  from  •.iiis  experience  wUl  be  particularly  important  to  the  potential 
problems  of  transitioning  a  PDSS  projea  to  a  ST'JIS  SEE. 

Unisys  STARS  is  using  the  Portable  Common  Tool  Environment  (PCTE)  produa  from  GIE  Eraeraude  primarily  for 
data  integrauon,  and  intends  to  use  HP’s  Softbenrh  product  for  control  integration.  PCTE  provides  control 
integration  mechanisms,  as  well.  Unisys  will  also  introduce  other  PCTE-based  horizontal  tool  products,  such  as  the 
European  Advanced  Software  Technology  (EAST)  environment  from  SFGL. 
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UNISYS  STARS  SEE  EVOLUTION  STRATEGY 

BASELINE  SEE 


•  Unisys  Defense  Systems’  standard  SEE 

-  Loosely  integrated  collection  of  softvtare  development  support  tools 

-  Software  development  process  manual 

-  DoD-STD-2167A  product-oriented 

-  Primarily  intended  for  Ada  development 

•  Integration  technology 

-  Sun  Unix 

-  Local  area  network  (LAN)  with  Network  File  System  (NFS) 

-  Unix  shell  scripts 

-  “Manual”-ation 


IWvt  STAJiS 


The  Unisys  Defense  Systems  standird  sofnware  development  environment  is  in  use  by  both  production  and  IR&D 
projects  within  the  company. 

The  environment  consists  of  a  set  of  loosely  integrated  software  development  tools;  IDE’s  Software  through  Plaures 
product  suite:  READS,  a  Unisys  internally-developed  requirements  tool;  CCC  for  configuration  management; 
Interleaf  for  documentation  production;  the  20/20  spreadsheet  produa  for  metric  analysis;  and,  in  most  cases,  an  Ada 
compiler  (either  TcleSoft  or  VADS). 

A  important  aspect  of  this  standard  environment  is  that  Unisys  has  developed  a  sundard  software  development 

manual,  tailored  to  this  choice  of  tools.  This  manual  defines  the  processes  to  be  (manually)  executed  during 
various  phases  of  software  development  and  maintenance  projects  generaung  DoD-STD-2167A  compliant 
documenution.  The  manual  also  specifies  product  and  process  metrics  to  be  (manually)  collected;  these  metrics  arc 
analyzed  using  standard  spreadsheets. 
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UNISYS  STARS  SEE  EVOLUTION  STRATEGY 

UNISYS  INTERNAL  ALPHA  PROJECTS 


The  goal  of  the  Unisys  internal  alpha  projects  is  to  gain  experience  in  the  process  of  STARS  SEE  framework 
technology  transition.  The  primary  focus  of  these  alpha  projects  will  be  to  learn  how  to  deal  with  the  cultural  and 
technical  barricn  to  insertion  of  framework  integration  technology  (as  well  as  reuse  and  process  management 
automation)  into  an  existing  projea  with  an  existing  standard  set  of  software  development  tools  and  processes.  A 
secondary  focus  will  be  understanding  the  issues  related  to  replacing  a  project’s  current  “tools  of  choice”  with 
equivalent  tools  that  support  finer-grained  integration,  and  issues  related  to  enhancing  a  projert’s  current  “processes 
of  choice”  with  reuse-oriented  process  steps. 


103 


UNISYS  STARS  SEE  EVOLUTION  STRATEGY 

SEE  TECHNOLOGY  DEMONSTRATION 

PROCESS 


•  Internal  Unisys  Defense  Systems  alpha  projects  provide  a  vehicle  for 
the  learning  process 

•  Evolution  (1991-1993,  and  beyond) 

-  Toward  fine-grained  integration,  as  made  feasible  by  tool  vendors 

-  Toward  generic  IM  with  support  for  tailoring  to  tool  and  project 
specifics 

•  STARS  demonstration  project  (October  1993-1995,  and  beyond) 

-  STARS  will  provide  integration  technology,  experience  with  appljing 
that  technology  and  tailoring  assistance  for  the  specific  project 

-  Technology  support  level  will  evolve  over  the  project’s  lifetime 


Liulyt  STAMS  SSZlSti^iVGt 


Internal  Unisys  Defense  Systems  alpha  projects  will  provide  a  vehicle  for  learning  how  to  (and,  possibly,  how  not  toj 
insert  framework,  reuse,  and  process  automation  technology  into  an  existing  projea  environment  with  defined  and 
measured  standardized  processes.  These  internal  alpha  projects  will  focus  on  coarse-grained  integration  of  COTS 
tools  already  in  use  by  a  projea  team,  and  on  adapting  and  tailoring  the  SEE  via  tool-  and  projca-specific 
information  modeling. 

The  particular  software  development  tools,  reusable  assets  and  processes  used  for  the  internal  alpha  projects  may  or 
may  not  be  applicable  to,  or  even  available  for,  the  STARS  demonstration  projea. 

The  Unisys  STARS  team  will  bring  seleaed  framework  integration  technology,  experience  integrating  software 
development  tools  wuh  reuse  and  process  management  technology,  and  an  adaptable,  tailorablc  underlying  generic 
information  model  baseline  to  the  STARS  demonstration  projea.  The  Unisys  STARS  team  will  support  that 
demonstrauon  projea  in  the  initial  instantiauon,  tailoring,  and  training  for  use  of  a  projea-spedfic  SEE,  and  in 
supporting,  adapting  and  evolving  that  SEE  over  the  lifetime  of  the  demonstration.  Both  user  feedback  as  well  as 
availabibty  of  evolving  COTS  produa  technology  will  play  a  role  in  the  SEE  evolution  process. 
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UNISYS  STARS  SEE  EVOLUTION  STRATEGY 

INITIAL  DAI  A  INTEGRATION 


•  Encapsulate  baseline  SEE  tools  within  PCTE  OMS 

-  Translate  repositor}’  >iew  of  PCTE  to  Unix  File  System  >1ew  expected 
by  tools 

•  Integrate  Unisys  STARS  reuse  library  technology  with  baseline  SEE 
tools 

-  Rehost  existing  C.\IS-A  version  of  RLF 

-  Coarse-grained  usage  of  OMS  technology 

•  DoD-STD-2167A  product-oriented  Information  Model  (IM) 

-  Model  encapsulated  tools  (input/output  products) 

-  Model  static  structure  of  the  software  development  process  manual 

-  Software  Life  Cycle  Support  Environment  (SLCSE)  IM 


VtOft  STaXS  SESIShAidi.VCt 


During  the  1990  limeframc.  Unisy?  built  an  experimental  SEE  hosted  on  CAIS-A  vOoD-STD-1838AX  a  portable 
tool  integration  environment  incorporating  an  ERA-based  OMS.  Unisys  is  currently  upgrading  that  environment 
under  funding  from  NOSC.  This  experimental  SEE  focused  on  tool  data  integration.  CAIS-A  is  not  currently 
supported  by  any  commercial  products,  so  we  have  selected  a  PCTE-based  produa  to  form  the  baseline  for  the 
STARS  demonstration  projea  supported  by  Unisys.  Since  PCTE  also  incorporates  an  ERA-based  OMS,  Unisys  will 
be  able  to  leverage  considerable  cxpencnce  with  ERA-based  tool  data  integration.  Uni^  expects  to  be  able  to 
transition  this  PCTE  data  integration  experience  to  the  IBM  STARS  team  when  they  begin  to  address  data 
integration  issues. 

Since  the  Unisys  internal  alpha  projeas  will  be  producing  DoD-STD-2167A  compliant  documentation  produas,  the 
underlying  ERA  Information  Model  (IM)  used  with  PCTE  will  need  to  reflect  this  focus.  The  Air  Force  Rome 
Laboratory  has  been  sponsoring  a  projea  called  the  Software  Life  Cycle  Support  Environment  (SLCSE),  which 
includes  a  DoI>-STI>-2167A  ERA-based  LM.  U.nisys  plans  to  start  with  the  SLCSE  dau  schema  as  the  mitial 
baseline  for  the  PCTE  fM,  suitably  uilorcd  for  the  panicular  tools  used  within  Unisys.  The  Rome  Laboratory 
recently  awarded  a  contraa  to  ISSI  for  the  SLCSE  Enhancements  and  Demonstration  Program.  As  a  part  of  that 
program.  Enhanced  SLCSE  (E-SLCSE)  will  probably  adopt  the  PCTE  standard  OMS  interface.  Unisys  and  ISSI 
have  begun  discussions  that  should  lead  to  coordinated  efforts  to  move  the  SLCSE  IM  to  a  PCTE  technology  base. 
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UNISYS  STARS  SEE  EVOLUTION  STRATEGY 

DATA  INTEGRrVTION  EVOLUTION 


•  COTS  PCTE  OMS  technologj’  base  is  evolving  in  the  direction  of 
fine-grained  data  integration 

•  Vehicles  for  evaluation  of  fine-grained  data  integration  technology’ 

•  RLE,  RKADS 

-  Sofhvare  through  Pictures  version  5  (Open  Repository) 

•  Evolve  project-specific  IM  into  a  gent.  Ic,  tailorable,  IM 

-  TRW’s  Project  Master  Data  Base  (PMDB)  IM 

-  Initial  tailoring  to  DoD-STD-2167A  for  use  by  internal  project 

•  Sha’-e  lessons  learned  across  SIaRS  program 


STAfiS  SZ£  SXuMis  VC!! 


The  Unisv-s  STARS  team  Nviil  support  the  alpha  and  demonstration  projeos  with  whatever  PCTE  OMS  technology 
base  is  made  available  by  commercial  vendors  during  the  period  of  the  demonstration  projects.  The  anticipated 
progression  of  support  of  the  PCTE  standard  from  GIE  Emeraude  is  PCTE  1.5,  with  some  exteasions  frc.a  PCTE  + 
(Emeraude’s  V12  produa  baseline)  now.  PCTE+  compatibility  in  the  spring  of  1992,  and  ECMA  PCTE  compliance 
sometime  in  1993  (Emeraude's  V20  produa  baseline).  Beyond  this  evolution  vo  compliance  with  the  current  ECMA 
PCTE  standard,  PCTE  is  expeaed  to  e-/olve.  prior  to  the  end  of  the  ST.ARS  demonstration  projea.  in  thr  direaion 
of  supponmg  ieither  direaly  or  uiteroperatmg  with)  fine-grained  dtia  uiieg.'ation  technology.  Whethe’’  or  not  this  is 
applicable  to  ST.ARS  depends  bc-th  on  vendors  of  PCTE -compliant  tramework  p.od  uas  supponmg  the  new 
funaionality  and  on  software  development  tool  vendors  “openmg  up”  the  da'a  repc,.turv  acces.s  f’cilifes  of  their 
respeaive  tools.  For  example,  HP  is  proposing  what  they  are  calling  Extended  Tool  Integration  Serv.ces  fXTIS)  as  a 
combination  of  the  current  ECMA  PCTE  faaliues  for  coane-gramed  objeas  with  something  as  yet  undefmed  (at 
least  publicly)  to  suppon  fine-grained  objeas  as  the  produa  evolution  dixeaion  for  Softbench. 

Lnisys  is  planning  to  evaluate  the  .ability  of  currently  available  PCTE  O.MS  technology  to  suppon  fine-grained 
objeas.  Tnis  invesugaiion  could  he  done  with  a  number  of  vehicles,  such  as  RUF,  a  READS  conversion  from  the 
Ingres  RDBMS,  and  (the  not  yet  available)  release  5  of  IDE’s  CASE  tool  produa  suite,  which  will  mclude  an  open 
iniertace  to  the  underlying  data  rep'^sitory,  ailow-aig  miegrati.ari  of  the  IDE  toolset  on  top  of  any  data  repository 
technology  tiiat  can  suppion  IDE’s  open  repository  mtcrfaci,  such  as  PCTF,. 
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UNISYS  ST.YRS  SEE  EVOLUTION  STR.4TEGY 

INITL4L  CONTROL  LNTEGRATION 


•  Utilize  coarse-grained  control  integration  of  PCTE 

-  Execution  of  encapsulated  Unix  tools 

-  Transparent  distributed  invocation  of  tools 

•  Evaluate  HP  Softbench  BMS  technology 

-  Augmentation  and/or  replacement  for  PCTE  facilities 

-  IBM  STARS  team  lessons  learned 


U/ww  rrAJts  s££  vos: 


The  initial  use  of  control  integration  will  be  to  support  coarse-grained  tool  composition,  providing  straightforward 
automation  of  tool  invocation.  The  ability  to  automatically  invoke  the  appropriate  tool  to  view  a  reusable  asset  just 
lo-ated  within  the  reuse  library  (e.g.,  a  syniax-direaed  text  editor  for  source  code,  a  graphical  design  editor  for  a 
design  doaimrnt)  is  an  example  of  control  integration. 

The  Unisys  STARS  team  intends  to  focus  the  majority  of  its  resources  initially  on  data  integration.  We  therefore  plan 
to  rely  heavily  on  the  werk  done  by  the  IBM  STARS  team  in  the  control  integiation  area,  as  their  resources  wiU 
muialiy  focus  on  control  integration. 
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UNISYS  STARS  SEE  EN^OLLTION  STR.\TEGY 

PCTE  INTEGK4TION 


Coacrat  lategrscioa 


OaU 


Presentation 

Integration 


■  STaXS  SS£  SluAiti.VCIl 


TTiis  is  a  depiaion  of  the  framework  integration  space  provided  by  PC7TE. 


109 


UNISYS  STARS  SEE  EVOLUTION  STRATEGY 

CONlTiOL  INTEGRATION  EVOLUTION 


•  Priman  technologies:  PCTE  and  HP  Softbench  BMS 

-  BMS  provides  flexible  event  triggering 

•  Evolve  from  coarse-  to  fine-grained  control  integration 

-  As  feasible,  add  embedded  control  “inside”  tool  boundaries 

-  PCTE:  message  queues,  notification,  triggers 

-  HP  Softbench:  message  generation  for  significant  “tool  events” 

•  Leverage  control  integration  experience  of  IBM  STARS  team 


L  STAjiS  S££.  Sfmldt. 


The  Unisys  STARS  team  plans  to  use  RJLF  and'or  Rr  ADS  as  readily  available  platforms  for  incorporating 
fme-grained,  embedded  control  integration.  Additional  opportunities  for  incorporation  of  fine-grained  control 
integration  beween  tools  depends  on  the  tool  vendors  “opening  up”  their  tools  at  control  point  boundaries.  As  other 
tool  vendors,  such  as  IDE.  provide  support  for  HP  Softbench  and/or  PCTE  control  integration,  Unisys  will 
incorporate  those  capabilities  into  the  evolving  SEE. 


no 


This  is  a  depiction  of  '.he  fnimewoik  integniion  space  provided  by  PCTE  in  combination  with  HP’s  Softbench 
Broadcast  Message  Server  (BMS)  technology. 


UNISYS  STARS  SEE  EVOLUTION  STRATEGY 

PRESENTATION  INTEGRATION 


•  STARS  has  chosen  Motif  as  the  standard  “look-and-feel”  technology 

•  H?  Softbench  and  EAST  proMde  environment-specific  “look-and-feel” 
toolkits  (Motif-based) 

•  “Look-and-feel”  commonality  across  tools  and  the  environment  is 

dependent  on  vendors/implementors 


rTAXS  SE£  StMii'CIf 


The  Urusyv  SEE  aaiviues  wiU  not  focus  on  presentation  integration  issues,  other  than  as  a  b>produa  of  using  tool 
encapsulation  facilities  provided  by  COTS  framework  products  such  as  HP  Softbench  and  EAST,  which  both  include 
facilities  for  providing  a  common  “look-and-feel." 
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o 


This  IS  a  aepiction  of  the  franicwork  integration  space  Unisys  STARS  expccu  to  be  using  provided  by  COTS 
technolog)'  for  the  demonstration  projea.  The  COTS  integration  space  may  expand  beyond  this,  depending  on 
evolution  of  produa  technology. 
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UNISYS  STARS  SEE  EVOLUTION  STRATEGY 

RELATIONSHIP  TO  PROCESS  FOCUS 


•  Process  integration  through  framework  senices 

•  Pro\ide  enabling  technologies  for: 

-  Non-obtrusive  collection  of  process/product  metrics 

-  Event-based  task  execution 

-  Process/project  management 

•  European  Advanced  Sof^vare  Technology  (EAST)  emironment 

-  Evaluation  for  potential  applicability  to  SEE 

-  PCTE-based  en>ironment  product 

-  Process  model  driven  environment 

-  Horizontal  tools:  CALS-corapliant  documentation,  CM, 
process/project  management 

•  Unisys  Defense  Systems  software  development  processes 

rrAAS  SE£:s>>^-yait 


The  relationship  to  the  process  '  ms  activities  is  to  provide  the  underlying  technology  to  support  process  integration. 
The  Unisys  STARS  process  focu  is  on  process  measurement  (automated  metric  coUcaion  and  analysis)  to  support 
measurement-driven  feedback.  The  baseline  technology  for  this  capability  is  the  Arcadia  Amadeus  prototype  from 
Dr.  Rjck  Selby  at  the  University  of  California  at  Irvine. 


Unisys  voll  evaluate  the  EAST  environment  as  a  potential  COTS  baseline  for  a  process-centered  environment. 

EAST  provides  process  and  projea  management  capabilities  tightly  integrated  with  documentation  and  configuration 
management  tools.  The  IBM  STARS  tea-m  'vill,  in  parallel,  be  evaluatmg  the  Entrepnse  II  environment,  which  is  a 
competitor  of  EAST.  Based  on  these  two  product  evaluations,  both  teams  may  (or  may  not)  decide  to  incorporate  one 
or  the  other  of  these  produas  in  them  respeaivc  SEE  solutions  provided  to  the  STARS  demonstration  projects. 


4* 


This  is  a  depicuon  of  the  framework  integraiion  space  Unisys  STARS  will  be  consid'Tng  for  use  for  the  STARS 
demonstration  projea  provided  by  prototype  technology.  This  may  become  COTS  integration  space  by  the  start  of,  or 
sometime  during,  t.'ie  ^ARS  demonstration  projea.  Objea  Management  Service  (OMS)  tpggers  are  not  currently 
pan  of  the  PCTE  standard,  nor  are  they  pan  of  the  GEE  Emeraude  PCTE  prodoa  at  this  time.  However,  Eraeraude 
has  a  prototype  implementation  of  triggers  in  a  variant  of  their  produo  built  for  a  research  project,  and  Unisys  has 
requested  access  to  that  variant  of  the  product  to  support  prototype  process  integration  experimentation. 
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UNISYS  STARS  SEE  EVOLUTION  STRATEGY 

RELATIONSHIP  TO  REUSE  FOCUS 


•  Integration  of  reuse  librar>’  technology  with  ether  tools 

-  Data  integration:  PCTE 

-  Control  integration:  possibly  PCTE  and/or  HP  Softbench  BMS 

•  Provide  enabling  technologies  for: 

-  Reuse  process  management 

-  Distributed  reuse  libraries 


C  w  STM  5E£  SiiM^<yc:0 


TTie  relauonshi-p  to  the  reuse  focus  aatviues  is  to  provide  the  underlyuig  technology  to  support  tight  integration  of 
reuse  library  technology  wth  other  softvore  development  tools.  The  purpose  of  this  reuse/tool  integration  is, 
uluraately.  to  support  the  introduction  of  reuse-based  processes  into  the  SEE. 
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UNISYS  STARS  SEE  EVOLUTION  STRATEGY 

SEE  CAPABILITY  PLAN 

1 

Jul  92 

Baseline  SEE  with  coarse  data  integration 

Lessens  learned  repons 

E.AST  and  HP  Softbcnch  evaluation  repons 

Oct  92 

Baseline  SEE  with  coarse  control-presentation  integration  -r  reuse  -r  process 
Stan  internal  Unisys  alpha  projeas 

Jan  93 

Refinement  of  baseline  SEE  based  on  user  feedback 

Lessons  learned  reports 

Jul  93 

Baseline  SEE  with  fine-grained  data  control  integration 

Lessons  learned  reports 

Initial  tailored  SEE  for  demonstration  projea 

Oa  93 

Demonstration  project  “begms" 

Oa  93  -  1995 

Incrementaily  refine  demonstration  projea  SEE 

Lessons  learned  reports 

ljm  staks  su  xtxA.  fc:i 


This  chan  dcpicis  ocpcaed  prcxjuas  and  major  planned  miles'.ones  of  the  Unisv-s  STARS  SEE  evolution  process. 
Internal  alpha  projects  must  stan  not  later  than  Oaobcr  1992  m  order  to  have  adequate  tune  to  gam  useful 
openence  to  ensure  success  of  the  STARS  demonstration  projcc’  begmnmg  m  Oaober  1993. 

Unisys  cxpeos  to  be  able  to  demonstrate  an  initial  baseline  SEE  at  the  STARS  Technology  Center  by  July  1992, 
incorporating  coarse-grained  data  integration,  adding  coarse-gramed  control  integration  to  that  baseline  by  Oaober 
1991  Unisys  will  have  an  initial  reuse  and  process  management  capability  available  for  use  by  the  internal  alpha 
projeas  in  Oaober  1992  as  well.  There  will  be  at  least  two  incremental  unprovement  releases  of  the  baselme  SEE 
delivered  to  the  alpha  projeas.  based  on  user  cxpenences  and  on  evolvmg  technology  availabibty. 

Unisys  expects  to  have  identified  the  STARS  deraonstrauon  projen  we  wall  be  supportmg  by  the  February  1993 
timeframe.  This  will  allow  sufficient  time  to  work  with  the  projea  pUnrung  team  to  define  an  mitial  msiantiation  and 
tailoring  of  a  projea-spccfic  SEE  by  July  1993.  This  lead  time  is  needed  to  allow  for  mifial  trainmg  of  the  SEE 
capabiliues  for  the  projea  team  pnor  to  the  start  of  the  demonstiatjon  projea  m  Oaober  1993. 
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UNISYS  STARS  SEE  EVOLUTION  STRATEGY 

SUMMARY 


STARS  Reuse  PCTE  Objea  Management 


L'Mifi  rtAja  St£lSlmldiiyC22 


The  Uaisys  STARS  SEE  evolution  strategy  focuses  primarily  on  developing  expertise  with  data  integration 
technology,  in  particular  with  developing  an  adapuble,  tailorable  Information  Model.  The  SEE  integration 
framework  will  also  incorporate  control  integration,  but  we  plan  to  rely  heavily  on  the  lessons  learned  and  experience 
of  the  IBM  STARS  team  using  HP's  Softbcnch  BMS  produa  technology,  rather  than  reinvent  the  experience  from 
ourselves.  The  Unisys  tea.m  will  utilize  the  preseiiuiion  integration  technology  provided  by  HP  Softbench,  and/or 
possibly  by  the  EAST  en>aronment. 

ECMA  PCTE  IS  the  key  component  for  coarse-grained  data  integratjon,  but  the  current  PCTE  standard  will  UJcely 
need  to  be  supplemented  with  additional  servx>:s  for  management  of  fuic-grained  data.  The  current  HP  Softbench 
BMS  technology  supports  coarse-grained  tool  compostoon,  but  likely  will  need  to  be  supplemented  by  additional 
fine-grained  tool-composition  mechanisms.  In  both  areas,  the  ability  to  capitalize  on  fine-grained  integration 
mechanisms  will  depend  on  software  development  tool  vendors  •‘opening  up”  their  products.  The  SEARS  program  as 
a  whole  will  be  working  with  industry  to  faolitate  product  evolution  in  this  direction. 

The  stratesr  is  to  “learn  by  doirg”  vn  preparation  for  supponuig  the  STARS  demonstration  proitet,  through 
uicrtmental  evoluuon  of  the  Unisys  I.  efense  Systems’  standard  baseline  SEE  in  the  context  of  internal  STARS- 
supponed  alpha  projects.  The  end  result  will  be  adapuble.  tailorable  SEE  mteg-miion  framrvork  technology  and 
experience  that  can  be  transitioned  to  the  STARS  dcmonstmtion  projea. 
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SEE  S«iM«ySaaB/VCl 


This  preservation  shows  the  Boeing  strategy  for  evolving  their  STARS  SEE.  SeveraJ  elements  of  our  strategy  are 
similar  to  those  of  IBM  and  Unisys.  This  is  to  be  expected  given  the  specifications  developed  jointly  by  the  three 
pnme.s  and  given  the  current  state  of  technology.  One  unique  element  of  our  strategy  is  our  alliance  with  the  Digital 
Equipment  Company  (DEC)  and  our  use  of  their  COHESION  product  seL 


BOEING  STARS  SEE  EVOLUTION  STRATEGY 

AGENDA 


•  Context 

•  Overview 

•  Evolution  process 

•  iiitegration  approach 

•  Process  and  reuse  focus 

•  SEE  Evolution  Plan 

•  Summary 


93  ftv^aaoi 


BOEING  STARS  SEE  EVOLUTION  STRATEGY 

BOEING  STARS  SEE  OVERVIEW 


•  Based  on  DEC  COHESION  framework 

-  Object-oriented  repository  based  on  ATIS  standard 

-  Process  enactment  integral  to  framework 

•  Integration  of  System  and  Software  Engineering 

-  Synergy  with  internal  Boeing  activities 

-  Computer  Aided  Project  Engineering  (CAPE) 

•  Systems  and  Software  Engineering  Organization 

•  Develop/maintain/build  from  SEE  system  speciHcations 

•  Incorporates  reuse  and  process  technology  products  and 

lessons  learned 

•  Incremental  development  via  iterative  model 


As  noted  in  the  introdurdon,  the  Boeing  STARS  SEE  is  based  (» the  DEC  COHESION  prciuct  set  This  includes 
their  framework  product,  CDD/Repository.  CDD/Repository  is  object-oriented  and  based  on  "A  Tool  Integration 
Standard"  (AUS).  This  standard  provides  for  a  self-defining  type  hierarchy,  a  set  of  services  for  managing  data 
within  the  repository,  and  a  set  of  services  dealing  with  method  (or  process)  enactment 

Another  feature  of  the  Boeing  SEE  is  its  support  to  both  systems  and  software  engineering.  This  integrated  approach 
to  systems  and  software  en^eering  is  synergistic  with  Boeing's  own  approach  to  system  development  For  example, 
one  effort  underway  at  Boeing  is  creation  of  a  support  environment  called  the  Computer  Aided  Projea  Engineering 
(CAPE)  environmem.  Lessons  learned  (m  CAPE  and  domain  specific  requirements  from  CAPE  will  assist  in  the 
evolution  of  the  Boeing  STARS  SEE 

CAPE  is  being  developed  by  the  Boeing  Defense  and  Space  Group's  Systems  aixl  Software  Engineering  Organization, 
the  same  organization  that  staffs  STARS.  This  organization  provides  policies,  procedures,  and  tools  to  support  an 
integrated  approach  to  systems  and  software  engineering.  These  proosdurcs  are  compatible  with  Government 
standards  such  as  MIL-STD-499A  and  DoD-STD-2167A  and,  as  such,  are  similar  to  procedures  found  in  other  large 
aerospace  firms.  They  should  prove  useful  as  test  cases  for  adapting  the  SEE  to  specific  processes. 

The  Boeing  SEE  will  be  created  based  on  Boeing  SEE  specifications  derived  from  specification  documents  developed 
by  STARS  joint  activity  groups.  A  chan  later  in  this  presenution  depicts  the  relationships  among  the  various  STARS 
documents. 

In  addition  to  commercial,  off-the-shelf  (COTS)  tools,  the  Boeing  STARS  SEE  will  incevporate  products  and  lessons 
learned  from  their  own  work  on  process  and  reuse  and  from  the  work  of  Unisys  and  IBM.  Note  that  our  strategy  in 
building  a  SEE  is  to  incorporate  and  integrate  tools  developed  elsewhere.  Our  SEE  will  be  built  incrementally  with 
>  periodic  releases.  Each  new  release  will  have  additional  functionality  and  will  provide  opportunities  for 
F  demonstrations  and  feedback. 
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BOEING  STARS  SEE  EVOLUTION  STRATEGY 

THE  SEE  EVOLUTION  PROCESS 


STARS 

T»ehnoIogy 

>C«nt*r 

and 

Boaing 

CAPE 


Like  the  IBM  and  Unisys  SEEs.  the  Boeing  STARS  SEE  will  evolve  with  time.  As  you  can  see  from  this  chart,  we 
plan  periodic  releases  as  the  SEE  evolves.  There  will  be  a  release  every  six  months,  each  release  ctxuaining  more 
functionality.  The  release  in  October  of  1993  will  be  used  on  a  demonstration  project  to  determine  the  effectiveness 
of  a  SEE  embodying  STARS  technology.  It  should  be  Mly  ftmctional  at  that  time.  Depending  on  the  feedback, 
subsequent  changes  and  new  releases  will  be  made  through  199S. 


The  large  circle  in  the  middle  of  this  chart  represents  our  SEE  development  process.  Note  the  two  major  inputs  to 
this  process.  STARS  requirements  are  all  of  those  requirements  emanating  bom  the  joint  activity  groups,  from  the 
demonstratiem  project,  and  from  ad-hoc  sources.  These  requirements  are  distilled  into  a  Boeing  SEE  spet^icaticni 
document  as  shown  on  a  later  chart  Products  used  by  this  process  come  from  the  commercial  sector  and  come  from 
work  being  done  on  other  STARS  tasks  in  the  area  of  reuse  and  process. 

A  very  important  component  of  the  STARS  program  is  technology  transfer.  It  order  to  bring  about  significant 
productivity  improvements  in  system  development  and  maintenance  we  need  to  nansitiem  new  products,  ideas,  and 
other  technology  into  Government  and  Industry. 

Inside  the  big  circle,  which  represents  the  process  for  building  the  SEE,  are  four  sub-processes.  Beginning  with  the 
System  Spediicatioo  sub-pnx^  and  proceeding  counter-clockwise,  each  tme  of  the  four  sub-processes  tends  to  be 
sequentially  executed.  Of  course,  we  (kn't  live  in  a  perfect  world,  so  sometimes  a  subprocess  is  revisited  during  a 
single  six-month  increment.  Major  outputs  from  ea^  phase  (sub-process)are  shown  flowing  from  one  phase  to 
another. 


A  synopsis  of  the  subprocesses  is  as  follows; 

1)  The  system  specification  process  basically  "distills''  all  of  the  various  requirements  into  a  single  Boeing  SEE 

sy'stem  specification. 

2)  This  specifications. is  analyzed  ana  a  set  uf  requirements  to  be  addressed  in  the  design  and  build  phase  is  allocated. 

3)  The  design  and  build  phase  takes  the  allocated  requirements,  builds  a  SEE  and  hands  it  over  for  testing. 

4)  Once  the  system  is  tested,  it  is  made  available  to  the  "outside  world"  (as  depicted  on  the  chart).  Lessons  are  also 

made  available  for  the  next  pass  around  the  loop. 
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As  illustrated  on  the  preceding  chart,  the  develq)  process  is  predicated  on  a  set  of  requirements  from  various 
sources.  This  chart  shows  how  those  documents  are  used  to  direct  the  development  of  the  STARS  SEE.  As  noted  on 
the  legend,  the  solid  airow  can  be  used  to  show  what  document  is  based  on  what  other  document,  this  typically  has 
meant  a  precedence  relationship.  That  is,  the  Framework  Requirements  and  Criteria  (FRAC)  preceded  the  STARS 
Standards  Portfolio  (SSP);  standards  pre«ded  their  incorporation  into  the  SSP.  On  the  other  hanrf,  the  Process 
Operational  Concept  Document  (POCD)  and  the  Reuse  Concept  of  Operations  (CONOPS)  document,  have  been 
developed  in  parallel.  The  dashed  arrow  shows  that  there  is  some  relationship  tetween  the  two  documents,  but  not  a 
strict  dependency. 

The  FRAC,  SSP,  Reuse  CONORS,  and  Asset  Library  Open  Framework  (ALOAF)  documents  have  been  developed  by 
STARS  joint  activity  groups.  Standards  been  develop  by  various  standards  bodies,  and  the  Boeing  Process  Model  is 
specific  to  Boeing.  The  SEE  System  Specification  is  unique  to  the  Boeing  STARS  SEE. 
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BOEING  STARS  SEE  EVOLUTION  STRATEGY 

COHESION  INTEGRATION  APPROACH 


Coatrol  Integrution 


DaU 

Integration 


saMrnm  StamolHtm/Wf 


Ttae  chart,  which  shows  the  three  dimeosioos  of  ioiegration,  also  shows  how  COHESION  products  map  to  the  various 
dimensions.  It  is  important  to  note  diat  the  products  shown  here  are  FRAMEWORK  products.  That  is.  this  chart  does 
not  depict  tools.  Rather,  it  depicts  those  services  that  enabt?  a  SEE  to  be  built  and  provide  some  granularity  of 
integration.  The  concept  of  fme  versus  coane  granularity  is  reflected  on  the  chart  For  instance,  data  integration 
between  two  tools  is  considered  to  be  of  coarse  granularity  S  they  communicate  by  exchanging  data  via  files.  On  the 
other  hand,  fine  granularity  data  iiuegration  between  two  tools  is  realized  when  they  share  data  v<a  a  common 
repository. 

In  terms  of  dau  integration,  CDD/Repository  provides  the  ability  to  have  fine  integration.  This  allows  what  we  call  a 
repository-centered  SEE.  A  later  chart  will  provide  more  information  as  to  what  types  of  tools  will  populate  our 
SEE.  Our  current  environriKnt  which  is  being  demonstrated  at  STARS91  already  supports  fine-grained  integration. 
Toe  trick  is  continuing  to  populate  our  SEE  with  tools  which  will  share  a  common  information  model  and  provide 
adequate  performance. 

Aspects  of  control  integration  are  supported  via  the  COHESION  products,  CDD/Repository  and  Application  Conaol 
Architecture  Services  (ACAS).  ACAS  is  desigMd  to  provide  integration  of  third  party  tools  that  do  not  share  a 
common  repository.  ACAS  provide  a  means  to  integrate  tools  via  message  passing.  CDD/Repository,  which 
implements  A  Tool  Integration  Standard  (ATIS),  provides  a  feature  called  preambles  and  postambles.  This  capability 
will  cause  procedures  respecr'v*!ly  to  be  invoked  prior  to  invocation  of  a  method  (preamble)  and/or  after  invocation 
of  a  method  (postamble). 


Granularity  of  presenution  integration  is  shown  on  the  bottom  left  scale.  Like  IBM  and  Unisys,  Boeing  will  be  using 
the  STARS  standard  interface.  Motif.  The  DEC  COHESION  product,  VUTT,  is  a  user  interface  generator,  that 
generates  Motif-based  interfaces.  This  product  will  be  incorporated  into  the  Boeing  SEE  as  required. 


BOEING  STARS  SEE  EVOLUTION  STRATEGY 

CAPABILITY  FOCUS:  PROCESS 


•  SEE  is  process-driven 

-  Process  control  part  of  the  framework 

-  Currently  prearo'^ies  and  postambles 

-  Evolving  concept  of  control  points  and  policies 

•  Process  development  based  on  Process  Operational  Concept 
Document  (POCD) 

•  Using  Proto  +  and  RDD  for  process  modeling 

•  Process  enactment  based  on  high  level  specification 


One  of  the  key  feetures  of  the  STARS  SEEs  is  that  they  are  process-driven.  That  is.  the  SEE  has  bnilt  into  it,  some 
knowledge  of  the  user's  process  so  that  it  behaves  as  the  user  would  expect  This  may  be  in  the  automatic  invocation 
of  processes,  the  ordering  of  processes,  built-in  audits,  process  metrics,  and  other  process-related  features.  Through 
the  use  of  COHESION,  certain  features  of  process  control  are  built  into  the  framework.  That  is,  the  CDD/Repository 
provides  not  only  for  the  invocation  of  methods,  it  provides  for  preambles  and  postambles.  A  preamble  is  simply  a 
user-defmed  program  that  executes  prior  to  a  meih^,  and  a  postamble  is  a  user-defmed  program  that  executes  after 
a  method.  Cumntly,  working  as  a  subcontractor  to  Boeing.  HoneyweU  is  evolving  a  technique  using  control  points 
and  policies  to  control  method  invocatioa  Control  points  and  policies  provide  a  rich  set  of  process  control 
mechanisms  that  can  be  used  to  enhartce  the  c^abilities  of  CDD/Repositoiy's  preambles  and  postambles. 

As  shown  on  an  earlier  chart,  the  incc^  poration  of  process  technology  would  be  predicated  on  the  specifications 
found  in  the  Process  Operational  Concept  Document  (POCD).  On  functions  specified  in  this  document  is  process 
modelling.  Currently  experiments  are  being  conducted  using  ProUH-  and  RDD  for  process  modelling.  As  these  tools 
prove  effective  for  process  modellirg,  Usey  '■'ill  b3  incorporated  into  the  Boeing  SEE. 

Currently  control  points  and  policies  have  to  be  wriuen  in  C  or  Ada,  based  on  a  some  sort  of  high  level  process 
model  or  specification.  Thus  the  translaticn  of  a  process  model  to  enactable  control  points  and  policies  is 
cumbersome  and  labor  intensive.  As  a  result,  HoneyweU  not  only  is  building  mechanisms  for  process  enactment  using 
control  points  and  poUcies,  they  are  investigating  ways  in  which  a  high  level  process  specification  can  be  compiled 
directly  into  control  points  and  policies. 
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BOEING  STARS  SEE  EVOLUTION  STRATEGY 

CAPABILITY  FOCUS:  REUSE 


•  Centered  about  Reusable  Object  Access  Management 
System  (ROAMS) 

•  ROAMS  based  on  extensions  to  ATIS  type  hierarchy 

•  Provides  access  to  related  assets 

-  Source  code 

-  Test  plans 

•  Requirements 

•  User  Manuals 

•  Initial  methods  include 

-  View 

-  Retrieve 

•  Incremental  enhancements 

•  Administrative  functions 

•  Rule*based  search 


Reuse  capabilities  provided  by  the  Boeing  SEE  are  centered  about  a  tool  called  the  Reusable  Object  Access 
Management  System  (ROAMS).  This  system  takes  advanu^  of  the  extensible  ATIS  type  hierarchy  in 
CDD/Repository.  Using  the  concepts  inherent  the  object-oriented  daubase.  ROAMS  i^ovides  the  capability  to  define 
an  abstract  objea  called  an  "asset"  (refer  to  your  proceedings  in  the  Reuse  Track  for  more  informatioo  on  reuse 
assets).  An  asset  objea  then  has  several  sub-types  such  as:  source  code,  test  plans,  requirements,  user  manuals,  and  so 
on.  Because  the  system  is  extensible  it  is  a  simple  matter  to  extend  the  type  hierarchy  to  aeate  new  types  of  related 

Our  initial  implemenutiai,  which  can  be  seen  daring  the  demonstration  period,  supporu  the  capability  to  view  and 
retrieve  assets.  The  look  and  feel  of  ROAMS  is  consistent  with  other  Ihunework  tools  because  they  are  all  based  on  a 
standard  CDD/Repository  navigator  which  uses  Motif  widgets. 

ROAMS  will  continue  to  be  enhanced  as  our  SEE  evolves.  These  enhancements  will  include  administrative  functions 
for  asset  check-in  and  check-out  and  functions  for  rule-based  searching. 
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BOEING  STARS  SEE  EVOLUTION  STRATEGY 

SEE  EVOLUTION  PLAN 


Incremental  Release 

Process 

Reuse 

Other 

4/92 

•  Preambles  and 
Postambles 

•  Initial  release  of 

ROA.MS 

•  Loose  Integration  of 
requirtments/design/ 
documentation  tools 

•  Enhanced  project 
management 

10/92 

•  Process  modeling 
prototype 

•  Control  point  and 
poUcies  enactment 
mechanism 

•  ROAMS  rule  -id 
search 

•  Distributed  repository 

•  Enhanced  Ada 
development 
environment 
>  Performance  lessons- 
leamcd 

4/93 

•  AbQlty  to  enact  a 
process  specification 

•  System  architecture 
and  design  synthesis 

•  Performance  analysis 
tools 

•  Testing  tools 

•  Demonstration  project 
tools  identified 

10/93 

•  Process-driven  SEE 
supporting  system 
life-cycle 

•  Metrics 

•  Guidebook 

•  ROAMS  adminlstratlott 

tools  avaDable 

•  ROAMS  guidebook 

•  Demonstration  project 
tools  Integrated 

1(V9S 

- c 

JMMERCIALiZED  SUPPO 

_ 

RT - 

_ 

SSS  Sn>l;/>wva» 


The  plan  for  evolution  of  the  Boeing  SEE  is  shown  on  this  chan.  It  shows  ihe  functions,  features,  and  delivvable  that  wiD  be  available  at  six 
month  intervals.  It  should  be  noted  that  this  is  the  CURRENT  plan  Our  evolutionary  development  plan  u  iniended  to  provide  us  with  the 
flexibility  to  accommodate  change  as  we  disoover  more  about  process,  reuse  artd  tools  and  technology. 

In  the  area  of  process  we  are  currently  using  preambles  and  postambles  and  wiD  continoe  to  do  to  in  April  of  1992.  Subsequent  releases  cf  the 
SEE  will  provide  tools  for  process  modeling  (10/92)  and  process  enactment  directly  from  a  high  level  specificatian  (4^3).  By  October  of 
1993,  Che  SEE  will  conuin  a  process  spieciflcadon  for  the  system  development  life  cycle  and  tools  will  behave  accordingly.  Also  at  that  time, 
metrics  will  be  provided  as  well  as  a  guidebook  for  tailoring  the  SEFs  process. 

As  noted  earlier.  ROAMS  wiB  develop  incrementally.  The  initial  release  of  ROAMS  (eutrenily  being  demcnstraied  at  STARS  91)  will  be 
included  in  our  iRT.  SEE.  It  will  prot^Iy  have  minar  enhancemerus  at  that  time  depenliiu  on  lessons-Ieamed  in  the  interim.  Subsequent 
releases  of  ROAMS  will  support  lule-bt^  searches  and  distributed  repositories  (10/92).  This  wffl  be  followed  (4^3)  by  iniegrated 
capabilities  for  synthesizing  systmn  architectures  or  designs  based  on  domain  analysis.  By  October  19^.  tools  wiD  be  available  for 
evaluating  aiseis  for  acceptance  iniD  ROAMS.  Other  capabilities  for  easily  clsssif^ng  assets  Bid  getting  them  into  and  out  of  the  repository 
wiD  also  be  available. 

Tools  in  support  of  specific  functional  areas  wU]  be  ncrementally  added  to  the  SEE.  This  chan  purposely  does  not  identify  specific  products  - 
rather,  it  idmtifies  the  general  functional  areas  that  wiU  be  supported  across  time  We  believe  the  lessons  learned  about  integration  of  tools  into 
a  repository- based  is  more  important  than  the  particular  tool  brag  integrated.  We  need  to  be  able  to  develop  strategies  for  integrating  third 
party  tools  and  for  developing  common  information  modeb  for  repository-centered  SEEs.  The  lessons  we  learn  and  the  leduiology  we 
devdop  can  then  be  transitioned  into  the  commercial  marketplace. 

We  anticipate  having  a  fully  populated  SEE  by  October  1993  in  order  to  support  a  STARS  demorstration  project 

The  demonstration  project  wiD  continue  through  October  199S,  and  (as  the  chart  indicates)  the  final  objective  is  to  have  the  tools  and 
technologies  in  the  SEE  supported  by  the  commercial  markeqpUre. 
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BOEING  STARS  SEE  EVOLU KON  STRATEGY 

POPULATED  SEE  OVERVIEW 


This  chart  is  a  view  of  the  fully  populated  Boeing  STARS  SEE,  showing  where  DEC  COHESION  products  fit  and 
where  other  tools  and  products  fit.  This  model  is  based  on  the  Eurq^ean  Computer  Manufacturing  Companies 
(ECMA)  fiamework  reference  model  and  is  used  for  depicting  and  describing  framewodc  services  and  their 
relationships. 

A  data  repository  and  associated  data  migration  services  are  provided  by  the  CDD/Repository  produa  which 
implements  the  ATIS  standard.  COD/Repository  provides  a  self-defining  type  hierarchy  that  allows  the  definition  of 
data  and  meta-dau  alike.  The  type  hierarchy  can  be  extended  to  allow  the  definition  of  domain  specific  types 
together  with  their  attributes,  relationships,  and  methods.  The  currem  release  of  the  Boeing  SEE  has  been  ^xt«^dfd 
to  accommodate  the  classifying  of  some  types  of  assets  and  to  allow  the  integration  of  project  management  and 
program  development  data. 

Task  management  services  are  supported  by  both  ACAS  and  CDD/Repository.  These  services  will  be  those  used  to 
implement  process  invocation  and  control  using  preambles,  pc'tambles,  control  points,  and  policies.  The  user 
interface  is  supported  by  Motif. 

This  chart  also  shows  tool  slots  populated  with  those  types  of  tools  that  we  plan  on  having  in  our  environment.  Again, 
we  have  avoided  using  specific  product  names.  What  we  are  primarily  concerned  about  are  the  techniques  used  for 
tool  integration  and  the  common  information  model  in  the  repository. 
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BOEING  STARS  SEE  EVOLUTION  STRATEGY 

SUMMARY 


•  Boeing/STARS  SEE  predicated  on  COTS  solution 

•  Incremental  development  process  provides  flexibility 

•  Technology  transition  is  a  key  component 


In  summary,  our  strategy  is  predicated  on  COTS  solutions.  Our  alliance  witb  DEC  and  our  use  of  their  COHESION 
framework  prouucis  is  a  key  pan  of  this  strategy.  Our  inaemenul  development  strategy  will  enable  us  to  be  flexible 
as  requirements  change,  new  lessons  are  learnt  and  new  products  become  available.  Fmally,  it  is  important  to 
understand  that  creation  of  a  SEE  is  not  the  primary  purpose  of  our  work.  Rather,  our  work,  like  the  rest  of  the 
STARS  effort,  is  focused  on  technology  tracsfer.  Our  intent  is  to  provide  Government  and  Industry  technology  for 
accelerating  improvemems  in  software  development  and  maintenance  •  improvements  that  will  enable  us  to  build 
better  systems  quicker  and  cheaper. 
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Acronymns  used  in  this  Presentation 

ACAS  •  Application  Control  Architecture  Services 

ALOAF  -  Asset  Library  Open  Framework 

ATIS  -  A  Tool  Integration  Standard 

CAPE  -  Cmpuur  Aided  Project  Engineering 

CDO  -  Common  Data  Dictionary 

CONOPS  -  Concept  of  Operations 

COTS  -  Commercial,  Ofi-The-Shelf 

DEC  •  Digital  Equipment  Company 

ECMA  •  European  Computer  Manufacturers  Association 

FRAC  -  Framework  Requirements  and  Criteria 

IBM  •  Intemadonal  Business  Machnies 

POCD  -  Process  Operational  Concept  Document 

RDD  •  Requirements  Driven  Design 

ROAMS  •  Reusable  Object  Access  Management  System 

SEE  •  Software  Engineering  Environment 

SSP  •  STARS  Standards  Portfolio 

STARS  -  Software  Technology  for  Adaptable,  Reliable  Systems 
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This  model  is  derived  from  the  change  agent  model  used  in 
diffusion  research.  Change  agents  provide  a  link  between 
produceis  and  consumers,  helping  to  translate  the  mearung 
and  implications  of  the  technology  to  the  potential  users  in  the 
users'  own  terminology.  This  cSagram  depicts  roles  in  one 
maturation  transaction.  Players  in  each  bubble  gather  and 
process  information,  add  value,  and  translate  the  results  for 
their  constituents.  Roles  are  not  always  equated  with  specific 
individuals.  The  players  within  each  bubble  address  issues 
relevant  to  their  context: 

•  organizational  issues 

•  innovation  issues 

•  commitment  issues 

Most  work  to  date  focuses  on  the  "push*  side  of  the  model. 
Advances  in  marketing  and  dissemination  in  general  have  led 
this  effort.  It  is  important  to  note  that  the  models  and  issues  are 
the  same  for  entities  across  the  diagram.  The  later  sections  of 
this  tutorial  focus  on  improving  the  transition  capabilities  on  the 
"pull*  side  of  the  equation. 
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Technology  Transition  Basics 


Any  technology  is  ”new”  in  a  context  where  it  hasn't  been  used 
before.  Technology  trartsition,  at  the  most  basic  level,  means 
taWng  a  "generic”  technology  and  mapping  it  into  a  specific 
organizational  context  Technology  is  "generic”  because  of  the 
assumptions  made  by  its  builders  about  the  contexts  of  its 
potential  users.  Even  with  good  market  analyses  or 
requirements  analyses,  there  is  never  a  perfect  match  between 
these  assumptions  and  the  specifics  of  the  context  in  which  it  will 
be  used.  And  those  who  know  the  technology  seldom  know 
enough  about  the  specific  context  to  do  this  mapping  without 
help.  Thus  we  use  the  model  of  collaboration  between 
technology  experts  and  context  experts,  i.e.,  users.  Working 
together,  people  with  these  different  perspectives  can  make  the 
match,  most  likely  adapting  both  context  and  technology  in  that 
process  (this  is  the  concept  of  "mutual  adaptation”,  as  described 
by  Dorothy  Leonard-Barton's  work  on  innovations  such  as  expert 
systems  (Leonard-Barton  88]). 

Another  way  of  describing  what  happens  here  is  to  say  that 
this  mapping  process  requires  orchestrating  the  actions  that 
move  people  up  the  commitment  curve. 


Technology  Development  Process 


This  generalized  research  and  development  process  is  typical 
of  those  found  in  the  R&O  management  literature,  in  this 
model  the  feedback  loops  are  omitted,  just  as  they  are  often 
omitted  in  the  "waterfalT  model  of  software  development 

Most  often  this  model  is  used  to  describe  the  entire  technology 
development  process  from  raw  idea  to  finished  product  We 
are  using  the  model  a  Bttle  dfferentfy.  Few  technologies  evolve 
from  basic  science  to  finished  product  within  one  organization. 
We'd  like  to  use  this  model  as  a  process  that  recurs  within 
(fifferent  organizations  throughout  the  technology  maturation 
fife  cyde.  The  literature  on  the  diffusion  of  innovations  and 
computer-human  interaction  supports  this  idea  of 
•reinvention."  The  stages  In  the  diagram  have  different 
meanings  depending  on  the  missions,  skills,  and  motivations  in 
eadt  organizafion.  This  process  recurs  until  either  the  idea 
des  or  it  reaches  some  level  of  use  in  the  outside  world.  One 
¥vay  to  view  the  process  is  that  each  organization  adopts 
technologies  according  to  their  risk  profile  and  works  to 
reduce  the  risk  relevant  to  their  missicn,  adding  value  to  the 
overall  maturation  of  the  technology. 

How  does  this  maturation  occur? 
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IDA  Maturation  Study 

Software  technology  maturation  study  sponsored 
by  the  Software  Technology  for  Adaptable, 
Reliable  Systems  (STARS)  Program.  The  Institute 
for  Defense  Analyses  (IDA)  commissioned 
case  study  analyses  of  14  technologies: 


•  knowladgc^aaad  systam 
« aoftWOT  angin— rtr^ 

•  forma)  vartfleation  tsetinology 

•  oomptltf  construction 

•  fTwtrlcs 

•  abstract  data  typos 

•  structurod  programming 


>  SCR  mothodology 
.DoD-STD-SOS 
>AFR  800-14 

•  cost  models 

•  SmalltaBc-eo 
-SRQI 

•  Unix 


[Redwine  84]  was  commissioned  by  the  STARS  Program. 
Between  February  and  May  1 984,  in^iepth  case  studes  were 
created  for  each  technology  listed  on  the  slide.  The  case 
stucGes  focused  on  the  technical  activities  performed  at  different 
organizations  that  helped  to  mature  each  technology.  Some  of 
this  list  may  not  be  famiTiarto  ail  in  the  audience: 

•  Naval  Research  Laboratory  (NRL)  Software  Cost 
Reduction  (SCR)  Project  -  A-7E  study  done  by  Pamas  et 
al. 

•  DoD-STD-SDS  -  precursor  to  DoD-STD-21 67A 

•  AFR  800-1 4  -  "Lifecycle  Management  of  Computer 
Resources  in  Systems”  -  This  regulation  e.stabiishes 
policy  for  the  acquisition  and  support  of  computer 
resources.” 

•  SREM  •  Systems  Requirements  Engineering  Methodology 
developed  by  TRW,  Huntsville,  under  the  sponsorship  of 
the  Army’s  Ballistic  Missile  Defense  Advan^  Technology 
Center  (BMDATC).  Initially  looked  at  requirements  and 
specification  •  TRW  has  extended  SREM  for  use  by  other 
customers. 

The  authors  provided  a  timeline  for  the  major  events  in  the 
maturation  of  each  technology  so  that  the  technologies  could  be 
"measured”  using  a  common  yardstick. 
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■r-  enqln— rtn^  fcwtftuH _ _ _ _ _ 

Teclmology  Maturation  Framework 

The  evolution  of  the  technologies  was  described 
using  a  staged  maturation  process: 

•  basic  research 

•  concept  formulation 

•  development  and  extension 

•  internal  enhancement  and  exploration 

•  external  enhancement  and  exploration 

•  popularization 

_ / 

Using  these  timelines,  the  authors  of  the  report  mapped  the 
technical  and  transition  activities  into  this  maturation 
framework: 


•  basic  research:  appearance  of  a  key  idea  underiying  the 
technology  or  a  dear  articulation  of  the  problem 

•  con^pt  formulation:  dear  definition  of  solution  approach 
via  a  seminal  paper  or  demo 

•  development  and  extendon:  usable  capabilities  become 
available 

•  enhancement  and  exploration  (internal):  shift  to  usage 
outside  the  development  group 

•  enhancement  and  exploration  (external):  substarrtial 
evidence  of  value  and  applicability 

•  popularization:  at  40%  and  70%  market  penetration  levels 

A  major  point  brought  out  in  the  case  studies  is  that  the  lack  of 
sharing  of  knowledge  and  experience  with  a  technology  across 
organizational  boundaries  greatly  inhibited  the  transition  of  that 
technology.  As  we  discussed  earlier,  this  lack  of  sharing 
results  in  reinvention  of  the  technology  within  the  multiple 
contexts  adopting  the  tecnnology.  We  posit  that  this 
reinvention  contributes  to  the  authors’  finding  that  technology 
maturation,  as  they  defined  it  takes  18  W-  3  years. 
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Botti  Mivkluais  and  groups  make  oommitiTienis  to  the  adoption  of 
new  technologies  in  a  regular  pattern: 


•  Contact 'the  transition  target  has  had  contact  with  the  technology 
through  some  means,  e.g„  documents,  brietings,  marketing  information, 
etc. 

•  Awareness -that  contact  (or  others)  make  the  target  aware  of  the  existence 

of  the  technology. 

«  Understarxfing  -  the  target  understands  the  technology  wefl  enough 
to  be  conversant  in  the  relevant  details. 

•  Trial  use  -  the  target  agrees  to  use  the  technology  tor  some  purpose 

on  atrial  basis,  e.g.,  a  pflot  project,  prototype  development,  etc.  This 
is  often  done  to  facifitate  the  ’adoption”  dedsioa 

•  Adoption -the  target  agrees  to  use  the  technology  more  widely  within 
their  organization  for  an  application  that  is  related  to  the  targefs 
business  puiporse 

•  Institutionaiization  •  the  use  of  the  technology  is  made  part  of  the 
standard  practioes  of  the  organizations 

There  si  an  enterplay  between  the  oommitment  curve  and  the  models  from 
Rogers  and  Curtis: 

•  Dflerent  information  needs 

•  Different  time  frames 

•  D9ferent  success  criteria 


a 


10 


o 


Receptiveness  to  New  Technology 
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The  study  of  the  diffusion  of  innovations  has  been  a  major 
research  area  since  the  1940s. *  *Diffusion  is  the  process  by 
which  an  innovation  \s  communicatefi  through  certain  channels 
over  time  among  members  of  a  sodai  systenf  [Rogers  83, 
p.5.].  The  beil  curve  represents  classes  of  potential  adopters: 

•  innovators  —  venturesome,  cosmopolitan,  technical 
expertise,  often  control  financial  resources 

•  early  adopters  —  respectable,  oii^nion  leader,  role  model 

•  early  majority — delib^ate,  seldom  hold  leadership 
positions 

•  late  majority  —  skepticsti,  adopt  in  response  to  peers,  risk 
averse 

•  laggards  —  traditional,  often  isolated 

Membership  in  these  "market  segments"  changes  depending 
on  a  number  of  factors,  including  the  results  of  previous  change 
efforts,  the  type  of  technology,  and  an  individual's  role  in  the 
organization  or  change  effo^  This  model  can  also  be  viewed 
as  a  surrogate  measure  for  risk  aversion,  e.g.,  individuals  on 
the  left  side  of  the  model  are  more  willing  to  take  a  chance  on  a 
new  technology. 

Maturation  extends  the  diffusion  concept  to  include 
value-adding  activities  performed  by  participants  in  the 
technology  development  life  cycle. 
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Technology  Implementation  Roles 

Champion 

Upper  mariagement  (authorizing  sponsor) 

Line  management  (reinforcing  sponsor) 

Change  agent 

Piiot  project  team  (first  users) 

Target  users  (balance  of  users) 


People  in  eadi  of  these  roles  experience  the  commitment  curve 
cSfferently  and  at  different  times.  For  example,  the  champion 
proceeds  up  the  curve  ahead  of  everyone  else  (probably  one  of 
the  Innovators  or  early  actopters  described  by  Rogers).  Let's 
take  a  look  at  what  level  of  commitment  is  required  when  by 
which  of  these  people  (or  groups  of  people). 


The  sponsor  role  at  the  upper  managemerit  level  provides 
resources,  strategic  and  policy  direction,  and  final  approval  to 
proceed  with  the  implementation  of  a  technology.  At  line 
managemern  level,  the  sponsor  may  authorize  resources  and 
drect  efforts  toward  planning  for  mpiementation  and  trial  use. 
The  product  champion  is  the  individual  who  initially  introducas 
the  idea  of  a  particular  technology,  and  informally  advocates  it, 
calling  it  to  the  attention  of  others.  The  change  agent  is  an 
indhridual  or  team,  drawn  from  line  management  or  software 
personnel,  who  does  the  detailed  planning  and  implementation 
of  the  technology.  The  pilot  project  team  tries  the  technology  for 
the  first  time  on  behalf  of  the  larger  organization.  The  target 
users  are  the  remainder  of  the  organization  who  will  eventually 
implement  the  technology.  Routine,  everyday  use  of  a 
technology  is  called  "irrstitutionalization”. 
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Very  generally,  the  timing  of  commitment  is  related  to  roles  within 
the  transition  process.  This  picture  gives  a  rough  idea  of  how 
different  participants  in  the  transition  process  proceed  through 
the  stages  represented  on  the  commitment  curve.  For  purposes 
of  managing  the  transition  process,  it  is  helpful  to  think  in  tenns 
of  two  categories  of  activies:  information  transfer,  and  technology 
implementation.  The  mechanisms  that  fall  into  the  former 
category  are  most  Dkely  faminar  to  you;  those  that  fall  into  the 
latter  category  may  be  less  so. 
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Commitment  Mechanisms  by  Role: 


Information  Transfer 


ri^rViTi'  TrMiiVi'iTiii^ri*’  ni’  I 


Information  transfer  is  often  confused  wtth  technology  transition,  whereas  in 
reality  it  is  only  part  of  technology  transSion.  it  is  an  irrportan  part,  because  I 
is  what  effects  contact,  awareness,  and  understanfing,  and  can  be  managed 
tnjch  more  eysternatiCBly  and  strategicaBy  that  B  typically  is.  Sowetspenda 
few  minutes  on  tt. 


Sponsors,  at  both  senior  and  middie  management  leveis,  need  information  as 
nuch  as  the  engineers  and  pracdboners  who  win  be  champions,  change 
agerss,  arxl  users.  They  are  often  forgotten,  or  th^  need  tor  Momation  is 
not  attended  to  early  enough.  One  wey  to  develop  a  group  of  pafertffsf 
sponsors  sv  wO  vO  ^nBRs^o^Mo^s  c^oso^fv 

wch  as  company  newspapers,  or  presetUtionB  SI  atnni  meetings  of 
corporate  technical  oommBtees,  the  opportunity  to  heir  about  new 
technologies  and  how  they  might  apply  to  the  organtzaiion.  InaddBionto 
describing  the  technologies  themselves.  B  can  be  heiptui  to  descrtie  how  other 
organizations  art  using  them,  and  how. 

Mechanisms  tor  technicai  personnei  are  very  tamOiar,  Induding  intormal 
ooBoquia  such  as  brown  b^  lunches;  itorariss;  demonstrations,  conferences, 
andsooa  Most  people  are  famSiarwBh  these,  and  have  some  ska  in  using 
these.  What  is  less  carefully  considered  is  to  whom  these  actfvfties  are 
targeted  and  In  what  sequence.  Use  of  the  oommiment  curve  along  wth 
some  analysis  of  potantial  users  can  hep  here. 
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Mechanisms  for  implementing  change  are  more  labor-intensive  than 
those  for  information  transfer,  and  thus  are  more  likely  to  be  used  once 
sponsorship  is  obtained  and  resources  for  transition  are  allocated. 
These  are  the  mechanisms  that  support  the  use  of  new  technology  in 
practice.  For  example,  without  ^ils  from  training,  new  users  are  often 
frustrated  and  waste  considerable  effort  attempting  to  learn  a  new 
technology  from  peers,  documentation,  or  experimentation.  Without 
proactive  standards  revi^on  or  waivers,  new  technology  which  is  being 
piloted  will  hit  roadblocks,  and  the  additiona]  resources  required  to 
communicate  with  standards  personnel  add  overhead  to  the  pilot  use, 
muddying  the  evaluation  of  the  technology.  Without  pilots  themselves, 
premature  attempts  are  made  to  use  new  technologies  with  no  "shake 
down*  period,  and  problems  of  technology  transition  are  often  blamed 
on  the  technology  itself,  which  then  gets  discarded. 

There  is  another  consideration  here  often  omitted  from  technology 
transition  planning.  Management  may  need  to  do  its  job  drfferentiy. 

The  classic  example  of  this  in  a  software  engineering  ccmext  is  how 
management  reacts  when  no  code  ts  immediately  produced  on  a  new 
software  project  Management  needs  to  be  educated  not  just  about  the 
technology  content,  but  also  about  the  changes  they  need  to  make  in 
their  own  practices,  such  as  how  they  track  indicators  that  technology 
implementation  is  proceeding  successfully.  Sometimes  management 
needs  new  skils  as  well  as  new  information. 
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Layered  Behavioral  Model 


V _ 

Curtis.  Krasner,  and  Iscoe  conducted  a  field  study  of  the 
software  design  process.  Between  May  and  August  1 986.  the 
research  team  conducted  interviews  with  personnel  on  19 
application  development  projects  in  9  companies.  The 
applications  ranged  in  size  from  24  to  1 000  KLCX;  and  included 
embedded  systems,  operating  systems,  Oomputer-Aded 
Design  (CAD),  and  telephony. 

While  their  research  focused  on  'creation,*  we  can  argue  that 
most  technoiogies  are  'reinvented*  in  each  context.  Any 
analysis  of  the  technology  maturation  and  adoption  process 
must  recognize  differences  in  orientations,  motivations,  and 
responsibilities. 

Depending  on  the  context,  needs,  and  possible  impacts  of  the 
technology,  those  seeking  to  implement  the  technology  may 
have  to  address  multiple  levels  within  the  organization.  John 
will  later  discuss  the  'cascadng  sponsorship*  across 
organizational  levels  that  is  often  required  to  implement  such 
technologies. 

Technology  maturation  and  adoption  is  a  learning  and 
knowledge  transfer  process.  (Curtis  88]  suggests  that  we  look 
at  cognition  and  motivation  to  understand  the  process.  The  next 
models  to  be  discussed  examine  issues  at  this  level. 
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Dynamics  of  Organizational  Change 


L«v«l  of  Loaming  Roquirod 


I  Ttm*  to  Uagnitud*  of  Toehnoiogical 

V  Adjust  Changs  Sought 

V: _ 


The  magnitude  of  a  technology-driven  change  depends  on  the 
overall  impact  of  the  technology  on  the  organization.  A  new 
design  method,  for  example,  may  be  pad  of  a  larger  effort  to 
change  the  way  an  organization  does  business  as  part  of  a 
quality  improvement  program. 

Conversely,  a  new  CASE  tool  may  only  be  used  in  a  small  part 
of  the  organization,  and  will  have  little  impact  beyond  a 
specialized  application. 

More  often  than  not,  the  advent  of  multiple  small  technologies 
can  be  seen  from  a  broader  perspective  as  a  larger  effort,  with 
greater  impact  on  the  organization. 
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Technology  Receptor  Punction 

Provide  technolo^  transition  expertise  and 
experience,  acquiring  and  maintaining  new  skills 
and  knowledge. 

Provide  support  for  technology  transition  plans  and 
implementation,  including  pilots. 

Gather  and  analyze  a  history  of  technology 
transition  plans  and  lessons. 


J 

NOftlS 

Let's  now  look  more  doseiy  at  the  technology  transition  function 
proposed  here. 


What  expertise  might  we  look  for  in  the  technology  transition 
function?  Candidates  need  not  have  an  MBA  in  technology 
management,  but  we  do  suggest  the  following; 

1.  Both  people  and  technical  skills 

2.  Credibility  with  technical  people  and  wiih  management 

3.  Experience  outside  this  particular  organization 

4.  Several  years  experience  inside  this  organization 

5.  Some  knowledge  of  technology  transition  (material  from  this 
tutorial,  and  from  the  SEPG  Guide  [Fowler  90]  would  be  helpful) 

6.  A  strong  interest  in  strategic  planning 
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Technology  Receptor  Function  -  2 

Facilitates  institutionalization  of  selected 
technologies 

Coordinates  working  groups  in  the  context  of 
overall  strategy 

Can  be  a  central  location  for  other  scarce 
skills  or  services,  e.g.,  process  definition,  metrics 
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Getting  started:  the  incremental 
approach  revisited 

Get  and  maintain  sponsorship. 

Begin  snnll:  start  with  one  working  group  focused 
on  one  technical  area. 

Use  this  first  effort  to  develop  planning  skiils  as  well 
as  technology  transition  skills. 

Grow  this  group  into  a  technology  receptor  function. 

Expedite  early  results,  but  keep  the  big  picture  in 
everyone’s  mind. 

Document  and  analyze  history  and  lessons. 


The  principles  weVe  discussed  for  technology  transition  also 
apply  to  putting  all  the  recommended  elements  into  place.  The 
set  of  three  key  elements-c^icaJ  approach,  plan  hierarchy, 
aiKi  organizational  archHecture-comprise  a  major  innovation  for 
most  organizations.  Unless  your  organization  has  most  of  these 
elements  already  in  place,  we  recommend  you  start  small.  Use 
a  single  working  group  as  a  prototype.  Doni  immediately 
establish  a  formal  steering  committee,  but  rather  work  informally 
with  one  or  two  key  managers  who  agree  to  act  as  sponsors. 
Develop  your  planning  and  technology  tranistion  skills  by  trying 
these  approaches  on  small-scale  change  efforts  where  )fou  can 
manage  the  risk  and  limit  tiie  visibiTity  of  your  mistakes.  When 
you  are  successful,  talk  up  the  resute  arid  sho  how  they 
support  progress  toward  the  ultimate  goal,  but  be  very  careful 
not  to  promise  too  much  too  soon.  Document  your  lessons  and 
use  your  initial  results  and  experience  to  bootstrap  a  larger 
effort  evolving  your  way  towards  a  full-fledged  and  systematic 
approach  to  ongoing  technology  transition. 
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Priscilla  Fowler 

Software  Engineering  Institute 

Internet:  pjf@seLcmu.eciu 

(412)  268-7748 

To  receive  full  copy  of  ICSE13  Tutorial  on  “Software 
TechnologyTransition,”  and  to  add  your  name  to 
a  software  technology  transition  mailing  list 
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STARS  91  CONFERENCE 
TECHNOLOGY  TRANSITION  STRATEGIES 


Joseph  Morin 
SEI 

03  December  1991 
(412)  26S-8594 
jiin@seLcmu.edu 
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This  presentation  irill  discuss  the  approach  STA"^  is  taking  with  respect  to 
technology  transition.  It  will  discuss  the  STARS  approach  to  information 
dissemination  as  weU  as  the  STA^  approach  to  working  with  receptor  groups 
in  order  to  accelerate  the  installation  and  adoption  of  megaprogramming 
support  products. 
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TRANSITION 

PRESENTATION  OUTLINE 


Reiatiooship  of  transitioo  to  STARS  Objectives. 
Accelerating  the  paradigm  shift. 

Transition  approach. 

Transition  impact. 

Roles  in  technology  transition. 

Effort  allocation  to  customer  interactions. 
Activity  summary. 

Conclusions. 
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TRANSITION 

STARS  PROGRAM  OBJECTIVES 


Objective  1: 

Democistrate  the  envisioned  paradigm  in  a  familiar  context. 

Objective  2: 

Provide  transition  support  to  reduce  the  adoption  risk  in  evolving  to  the 
envisioned  paradigm. 

Objective  3: 

Ensure  the  basic  capabilities  (process  and  product  technologies)  are  available  to 
suppori:  the  envisioned  paradigm. 


paradigm  shift  The  program's  objectives  are  designed  to  successfully  transfer 
technology;  however,  they  are  not  in  themselves  the  activities  of  technolo^ 
transition.  The  previous  speaker  has  outlined  models  of  technology  transition. 
Now  we  will  discuss  the  STARS  strategy  for  applying  those  models  to  actual 
transition  activities  which  support  the  program's  objectives.  For  our  purposes, 
the  focus  win  be  on  objectives  2  and  1  in  that  order.  Objective  3  is,  for  the  most 
part,  a  precondition  to  transition  activities  and  we  wiii  not  dwdl  on  it  in  this 
track. 
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TRANSITION 

ELEMENTS  OF  A  PARADIGM  SHIFT 

1)  Characteristics  of  the  current  paradigm  are  clearly  stated. 

2)  A  vision  of  the  desired  paradigm  easts. 

3)  Migration  paths  are  defined. 

4)  Evolutionary  and  revolutionary  aspects  of  the  new  paradigm  are  identified. 

5)  Technologies  to  support  the  paradigm  are  identified  and  worked  into  the 

available  technology  base. 

6)  Constituents  understroid  potential  benefits  of  the  new  paradigm. 

7)  Process  and  produ  ^  technologies  which  support  the  paradigm  are  successfully 

demonstrated. 


NOTES 
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ACCELERATING  THE  SHIFT 

1)  Paradigm  comparisons  in  DoD,  DARPA,  and  STARS  documents. 

Other  documentation  of  identified  and  latent  DoD  needs. 

2)  DARPA  Software  Technology  Strategy;  STARS  adaptation  of 

Megaprogramming  Vision. 

3)  SWAP;  SDP  2000;  CARDS  blueprint;  SEI CMM;  JLC  Reuse  Committee;... 

4)  Build  on  industry  starulards  and  commercial  base  to  facilitate  Evolution, 

Demonstrate  viability  and  benefit  of  revolutionary  aspects  (minimize). 

5)  DARPA  Software  programs;  STARS  process  I  reuse  /  technology  support 

thrusts;  coordination  among  DoD  software  technology  programs. 

6)  IDA  cost  modeling  work;  Cost  /  Benefit  data  from  demo  projects. 

7)  Alpha  Sc  Beta  usage;  TT  affiliates;  STARS  demonstrations  and  lessons 

learned. 


NOTES 

The  current  parachgm  and  the  envisioned  paradigm  are  described  in  a  variety 
of  existing  or  planned  documents. 

Migration  paths  are  being  defined  by  STARS  and  others: 

DoO's  Software  Action  Phin  (SWAP); 

STARS  Software  Development  Plan  (SDP)  of  the  year  2000; 

SEI's  Capability  Maturi^  Model  (CMM); 
etc. 

The  emphasis  is  on  evolutionary  rather  than  revolutionary  change. 

Use  of  commercial  standards  and  technologies  is  preferred 

The  technology  base  is  being  extended  to  support  the  new  paradigm 
via  STARS  work  ( discussed  in  the  other  tracks )  and  via  other 
DoD  software  programs. 

Cost  /  Benefit  determinations  and  a  base  of  success  stories  are  key 
factors  which  we  are  providing. 
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TRANSmON  AND  COMMUNTTY  INVOLVEMENT  I 

TECHNOLOGY  TRANSITION  APPROACH 


Trial 

Point  1 

Solutions 

c> 

Tectinoiogy 
Evolution  r  ' 

■-^-'Cultural 

bn'pa  tf  ''  '■,  ? 

c> 

Utaae 

•  Muttipl*  Omnt 

Tccnnelocy  Tnialtf  dhrts 

-N«WSi<ttMS 
— Confsfsnm 
-Bulletin  ilaiid 

•  Intepitnd  Tnetineloiy 
Tonsition  Stniip 
-  IdgitificiOfln  c< 
neeptar  fioupi 

-AlplWbaCi  Ua(* 

byPnmet 
-AffiStts  Proftsin 
-SrAfSXC 

•  Adepben  Bairier 

Risk  Reduction 

•  CARDS  must  blue- 
piint 

•  Losone  Lasnied 

•  Mifiiben  Paths 

e  Geneil  Community 
Mopbon 

•  SrA<SC>talei^ 

DTIC  dcsthbutBA 

•  Shotfun  dscibutian 
ol  STARS  Pont  sekf 

•  ASSET 

•  Padafins  inttrim 
praducs 

•  ASSET 

•  DennPicjecb 
-  Instanbated 

sdubons 

•  CoRunedalstd 
solubons 

tions 


NOTES 

As  you  can  see,  part  of  our  strata  is  to  apply  transition  principles  to  evolving 
our  transition  activities.  We  are  currently  at  the  point  of  moving  from  point 
solution  transition  activities  to  an  integrated  transition  strategy  under  the 
guidance  of  a  transition  coordinator  to  be  appointed  shortly.  The  initial 
strategy  and  activity  definition  will  be  evolved  through  use  and  in  light  of  it's 
cultural  impact  Dissemination  of  tr^nsiticn  lessons  learned  will  in  itself 
become  a  valuable  transition  activity  supporting  eventual  institutionalize  don. 


G 


C 
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Commitment 


TRANSITION 

STARS  TRANSITION  IMPACT 


NOTES 

STARS  transition  activities  are  intended  to  move  the  community  up 
the  adoption  curve  as  quickly  as  possible.  Different  members  of  the 
community  will  move  up  the  curve  at  different  times  and  rates.  Not 
surprisingly,  activities  designed  to  move  up  through  higher  levels  are 
more  resource  intensive  than  those  at  lower  levels.  This  will  be  dealt 
with  in  part  through  feedback  from  higher  level  activities  into  the 
information  base  being  disseminated  as  part  of  the  activities 
promoting  Awareness  and  Understanding.  The  program  will  not 
in  and  of  itself  carry  through  to  institutionalization.  However, 
the  way  will  be  paved  for  commercialisation  as  a  path  to 
institutionalization. 


29 


NOTES 

This  adaptation  of  a  chart  introduced  in  the  previous  talk  attempts  to 
shorr  the  roles  of  STAR5  program  participa^  in  the  transition 
process. 

The  program  itself  is  a  producer  and  consumer  of  technology.  It  is 
also  concerned  with  establishing  the  delivery  vehides  and  forums  needed  to 
bring  producers  and  consumers  together. 

The  primes,  subs,  and  affiliates  are  a  subset  of  the  overall  DoD  software 
industrial  base  with  which  we  are  concerned.  They  indude  members  focused 
on  production,  advocacy,  reception,  and  consumption  to  varying  degrees. 

The  involvement  of  this  group  and  the  lessons  learned  by  this  group  will 
be  directly  relevant  to  motivating  the  larger  industrial  base. 

The  Demo  projects  will  involve  the  major  commands  which  are  the  ultimate 
consumers  of  the  technology  as  well  as  the  contradors  and  support 
organizations  which  represent  them. 
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transition 

TRANSITION  ROLES  ELABORATED 


WHO 

WHAT 

WHY 

STARS 

PROGRAM 

Vision,  Direction, 
Resource,  Forum 

Motivation,  Sponsorship 

PRIMES 
&  SUBs 

Technology  maturation 
and  integration 

Technology  Base 

COMMERCIAL 
COUNTERPARTS 
&  AFFILIATES 

Technology  production 
and  advocacy 

Commercialization 
(supply  side) 

AFFILIATES 

Technology  reception 
and  consumption 

Commercialization 
(demand  side) 

DEMO 

PROJECTS 

Application 
development  case 
studies 

Adoption  Barriers 
"Validation'’ 

NOTES 

This  chart  elaborates  the  roles  just  intnxiuced  to  one  more  level  of  detail. 
It  is  not  all  encompassing;  however,  it  does  help  associate  the  activities 
(what)  of  the  participants  (who)  with  a  transition  objective  (why). 
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TRANSITION 

CUSTOMER  INTERACTIONS 


EFFORT /SKILL/ 


INTERACTION 


Broad 

(many) 


Narrow 

(few) 


NOTES 


Although  there  are  only  three  application  development  projects, 
there  will  be  a  significant  number  of  people  involved  in  each  and  as 
mentioned  the  results  will  become  part  of  the  general  informatioD 
distribution  activities. 


TRANSITION 

TT  SUPPORT  ACnVITIES  SUMMARY 


Create  Awareness  and 
Understanding  of 
Megaprogramming  Vision 
and  its  Benefits 


Identify  and  Work  with 
Receptor  Groups 


Provide  Incremental  Releases  of 
STARS  Technology  for  Review 
and  Feedback 


Collaborate  with  Vendors  for 
Commercialization  of 
Technologies  Supporting 
Megaprogramming 


Work  with  TT  and  Prime 
Afniiates  for  Trial  Usage 


Collect  and  Disseminate  Lessons 
Learned  wrt  Megaprogramming 


TRANSITION 

CONCLUSIONS 

•  STARS  Transition  Strategy  can  fulfill  the  program  objectives. 

•  Transition  is  premised  on  an  active  feedback  loop. 

•  Transition  will  not  occur  without  your  active  involvement: 

•  Maintain  your  status  as  an  Information  Affiliate; 

•  Seriously  consider  becoming  a  TT  Affiliate; 

•  In  either  case,  provide  us  feedback  on  the  vision,  the  process  and 
product  technologies,  our  transition  activities,  and  on  the  cultural 
impact  of  all  of  the  above. 


NOTES 


TannMaii/VC-U 


TECHNOLOGY  TRANSITION 

OUTLINE 


•  Software  Reuse  -  State-of-the-Practice 

•  Maturity  Levels 

•  Business  Practices 

•  Findings  and  Recommendations 

•  Lessons  Learned 

•  Regulatory  and  Business  Practices  >  Status 

•  Reuse  Guidebook 

•  Summary 

TtCHTMlBinONitOnsm  7 

Aorides  as  oTcrricw  of  what  issaes  win  be  coTcred  in  this  prwwrtathm. 
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TECHNOLOGY  TRANSITION 

STATE-OF-THE-PRACTICE 


•  Regulations 

•  Law 


Technical 

Environment 


Major  STAINS  Focus 

•  Reuse  CONORS 

•  RIG 

• ALOAF 


Lessons  Learned 
•  Business  Practices  Not 
Adequately  Addressed 

Jtat  TMSnMNItOVESPKi 


Focbms  on  tbe  dual  need  for  a  set  of  busmess/acquisitioa  policies  and  procedures  and 
an  appropriate  twhniral  enrironment  to  enable  integratioo  of  software  reuse  into  tbe 
acqntsitioa  process.  Condusion:  In  tbe  past,  busmess  practices  hare  been  inadequately 
addressed  to  adnere  successftd  integration. 
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TECHNOLOGY  TRANSITION 

TECHNICAL  VS.  BUSINESS  MATURITY 


Conclusions 

-  Technical  Maturity  is  Advancing;  Business  Maturity  Lags 

-  Lack  of  Refined  Business/Acquisition  Policies  and  Procedures 

-  Business  Support  Tools  (Guidebooks)  Needed  While  Regulatory/ 

Business  Environment  Matures 


Tlt3t7»AlBin(Mi»aWBnC4 


Eapamh  the  theme  tbit  busmcss  practices  sutarity  in  software  reuse  lags  far 
the  leirhairal  adraaces.  Also  hys  the  groundwork  for  asserting  Uie  necessity  for 
additional  work  and  products  to  fanprore  this  ogmfifMW  and  inappropriate  dbcrcpancy. 
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TECHNOLOGY  TRANSITION 

BUSINESS  PRACTICES:  FOUNDATION 

FOR  REUSE 


In  a  dugrammatic  fono,  suixfivides  the  reuse  structure  into  the  realms  of  the  reuse 
process,  todmoit^,  and  noo^technical  busiaess  practices.  The  diagram  is  to 

demoostrate  dee  oitiGal  role  played  by  busmess  practices  in  establishing  the  foundation 
to  support  aO  technical  initiatiTes.  Without  adequate  efforts  to  address  these  essential 
underpinnines,  the  entire  reuse  structure  could  collapse. 


Expudi  ibt  sttte-of-liie-pnKtice  in  reuse  thromfa  use  of  a  ydorial  rtpresmtatkm  of  a 
nainhff  of  inhibitora  hire  the  potwitiil  to  the  adueraacnt  of  in«seat 

rase  objectim.  Tlw  interior  box  higfaligfate  those  proposed  tools  that  may  assist  in 
nentraiirinc  the  infaihitors.  ftorides  another  iUnstntioa  of  the  oritical  importance  of 
bosines  pnctioes  ir  successful  reuse  implementation. 
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TECHNOLOGY  TRANSITION 

ATTITUDE/PERCEPTIONS 


•  Reuse  Not  Well  Understood 

•  Business  Practices  Tools  Primitive 

•  Focused  on  Individual  Programs 

•  Few  Available 

•  Not  Disseminated 

•  Non«TechnicaI  Community  Finds  It  "Too  Hard  To  Do" 

•  Technical  Community  Frustrated  by  Lack  of  Maturity  in  Business/ 
Acquisition  Policies  and  Procedures 

naiTXAtismotfiaons/vcT 


Addresses  some  of  tbe  oijamzatioaal  beharicr  issues  Uiat  impact  reuse. 
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TECHNOLOGY  TRANSITION 


ACQUISITION  REGULATIONS 


•  Difficult  to  Use 

•  Policies,  Regulations,  Clauses:  Poorly  Crafted  &  Poorly  Written 

•  Software  and  Technical  Data  Covered  Together 

-  Separate  Treatment  Required 

•  Commercialization  Not  Encouraged 


TtcantAssmoHittmsnc  t 


HigliUgbts  cuii'oidy  faisting  deficModcs  iwithin  the  acquistioa  ngulatiois  diat  sorcrn 
the  acquisitioo  of  software. 
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TECHNOLOGY  TRANSITION 

SOFTWARE  RIGHTS 


-DARBA- 


•  Use  of  Software  Rather  Than  Source  of  Funding  Determines  Rights 
Ownership 

•  Most  Contentious  Issue  Between  Indiistry  &  Government 

•  Commercialization  Not  Encouraged 

-  Government  Retention  of  Rights  is  First  Choice 

•  Disti  nction  Between  Software  "Rights”  and  Copyright  Not  Clear 

•  Acquisition  Personnel  Focus  on  "Rights”  Without  Understanding 

Copyright  Implications 


Ttm  njManoNitovEsivG  » 


Describes  the  ooofusioa  surrouading  this  issue,  aad  the  diflicultits  in  resolring  current 
contmtion  between  industry  and  the  Goremment. 
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-■  »»  <  h  •*-^  > 


Defines  the  tenns  ownership  and  copyright,  to  *«hanr»  understanding  of  the  issues 
inrolTed  in  their  use.  Highlights  the  confusion  that  arises,  since  the  inherent  rights 
specified  heron  often  conflict. 
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TECHNOLOGY  TRANSITION 

COPYRIGHT 


•  Regulations  Assume  Contractor  Will  Claim  Copyright  Regardless  of 
WTio  Owns  Software  Rights 

-  NASA  is  Different 


•  Copyright  Law  for  Software  is  Evolving 

-  Apple  Embroiled  in  Suit  Over  Use  of  the  "Look  and  Feel"  of  its 
Windows  Format 


7SCH  VtA^amOSlBOVESIVC  11 


Use  of  cepyrishts  is  described,  and  an  ecaoiple  of  current  Utigatioo  is  explored. 
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TECHNOLOGY  TRANSITION 

DERIVATIVE  WORKS 


DfiRRffi 


•  Many  Reuse  Products  Will  be  Derivative  Works  Software 

•  Who  "Owns"  the  Derivative  Work? 

•  Example:' 

1)  Government  has  Ownership  (Unlimited  Rights)  of  Software 

2)  Developing  Contractor  Retains  Copyright 

3)  New  Contractor  uses  Software  to  Create  a  Derivative  with 

Corporate  Funds 

4)  New  Contractor  Claims  Ownership,  BUT  Development  Contractor 

has  Retained  Copyright 

•  Result  =  Beginnings  of  a  Difficult  Situation 

TTCHTtMomoNiiowtsrfc  n 


I 


A  lurtfaer  compiiciticn  of  tbe  owoersbip  issue  is  addressed. 
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TECHNOLOGY  TRANSITION 

LIABILITIES 


•  Liability  Specter  Looms  in  Software  Reuse 

•  Warranties  are  Not  the  Answer 

•  Commercial  Warranties  Typically  Limited  to  Software  Itself  with 
no  Responsibility  for  Consequential  Damages 

-  Typical  Government  "Solution”  is  a  Clause  Absolving  Government 

of  Damages  in  any  Reuse  Environment 

•  Well  Documented  and  Maintained  Software  Will  Make  this  Issue  Moot 

-  Commercial  Software  Proves  the  Point 


Ttcn  TtMommito^ftsivc  » 


Issues  rdatiiig  to  the  liabCity  impedimeot  are  addressed. 
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TECHNOLOGY  TRANSITION 

PATENTS 


Addresses  ancertaindes  assoriatfd  with  appiTiog  patent  ^antection  to  software,  and 
mberent  difnailties  for  future  usen  of  sudi  software. 


TECHNOLOGY  TRANSITION 

LESSONS  LEARNED 


•  Attitudes  and  Perceptions  have  Significant  Impact 

•  Regulations,  Laws,  Policies  Contribute  to  "Degree  of  Difficulty"  and 
Confusion  on  Software  Reuse  Implementation 

•  Formal  Changes  Slow  to  Come 

•  Training  for  Acquisition  Personnel  Sparse,  at  Best 

•  Limited  Focused  Effort  to  Improve  Business  Policies  and  Procedures 


rtat  nuKsmofcaoms/m  it 


Addresses  some  of  tbe  lessoBS  leanxd  with  respect  to  each  of  tbe  mpedimaits 
prerioudy  outUned,  based  on  our  work  to  date.  A  satset  of  these  is  described,  with 
soiisequent  recocamendations  to  support  corredions/improTcmeiits. 
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TECHNOLOGY  TRANSITION 

RECOMMENDATIONS 


•  Reuse  Business  Training  Needed 

-  Development  of  Guidance  for  Executives,  Managers,  Workers 

•  Resulations  should  Provide  more  Focused  Discussion  of  Software 

o 

-  Industry  Involvement  Necessary  to  Refocus  Properly 

•  Readability  Enhancement  Required 

•  Contractor  Retention  of  Software  Rights  and  Copyright  should  be 

First  Preference 

•  Retention  Period  should  be  SuDlcient  to  Encourage 

Investment/Commercialization 


Ttcn  TluxmomaovEUvc  J7 


Discusses  issues  pertamiag  to  training,  modificatioD  of  regulations,  and  contractor 
retcntioa  of  rights  and  oopyrights. 
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TECHNOLOGY  TRANSITION 

RECOMMENDATIONS 


»  Develop  Methodologies/Incentives  to  Encourage  Derivative  Works 
(Reuse) 

-  Improve  Use  of  Licensing,  Royalties,  Award  and  Incentive  Fees 

•  Develop  Tools  (Guidebooks)  for  Acquisition  Personnel 

•  Create  a  ’’Win/Win'*  Environment  for  Original  Software  Developers 

and  Reusers 

•  Encourage  Reuse  by  Lessening  Recoupment  Burden 

-  Proposed  Changes  (25  Oct  91  Federal  Register)  are  Steps  in  Right 

Direction 

•  Develop  Tools  for  Acquisition  Personnel 

•  Minimize  ’’Liability  Issues”  Paranoia  through  Training 

•  Integrate  into  Guidebook 

TtcB  ntAtamoKEOwtsivc  » 


Discusses  means  of  stanulatisg  reuse. 
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TECHNOLOGY  TRANSITION 

STATUS 

•  FAR  Part  27  Remains  an  Interim  Rule 

-  Section  834  Senate  Defense  Authorization  Bill  Seeks  DoD-Industry 
Committee 

•  Recoupment  Policy  Under  Review  Within  DoD 

-  Oct  '91  Revision  Out  for  Comment 

•  Proposed  S1581  Would  Provide  Copyright  Protection  for  Software 
Produced  by  Government  Employees 

-  Mixed  Reviews  to  Date 

TtCJi  TKAMsmomaovtswc  20 


After  »>oHiiy  srees  of  coikxtbl,  lessons  leuned,  and  appropriate  rwiwnmcndatioiis,  ^e 
proride  the  eunrent  status  of  regulatory  initiatiTes. 


TECHNOLOGY  TRANSITION 

GUIDEBOOK  FOR  REUSE 


•  Addresses  Reuse  Concepts  aud  Strategies  from  Perspective  of  the 
Acquisition  Cycle 

Program  Phagg^/Milestones  from  DoDI  5000.2 


•  Reuse  Considerations  Integrated  into: 
Requirements  Definition 
Concept  Studies  and  Validations 
System  Development,  Production, 
Deployment,  Maintenance/Support 


Acquisition  Strategies 
Source  Selection  Evaluations 
RFPs/Clauses 

Contracts/SpecificationsAVork 

Statements 

TBOt  TKWSmONHOWESf^  21 


Wc  hare  wtabtished  a  bam  for  idendfTiog  key  Toids  in  business  practices  issues. 
Coosequeody,  in  order  to  support  software  reuse  objectms,  we  describe  our  ongoing 
work  aimed  toward  derdoping  a  guidebook  to  addrm  the  needs  higb^erd 
acquisitioa  executiTes. 


TECHNOLOGY  TRANSITION 

SUMMARY 


•  Continue  to  Support/Press  for  Regulatory  Change 

•  Provide  Incentives  to  Industry  and  Government 

•  Guidebooks  for  Reuse 

•  Acquisition/Business  Processes  and  Contract  Language 
-  Executive,  Managerial,  Working  Level 

•  Training  and  Support  to  Personnel  and  Individual  Projects 


TtCHTtAKZnomiOVESn’GS 


Rccsfis  imporeuioe  of  addressing  key  business  practices  issues,  in  order  to  ensure  future 
satress  of  reuse  initiatiTcs. 
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In  eailier  presentations,  STARS  demonstration  projects  have  been  mentioned.  This  presentation  pro¬ 
vides  a  more  in-depth  look  at  STARS  demonstration  projects. 


STARS  Demonstration  Projects 

OVERVIEW 

Motivat:lon 

What 

How 

Status 

hllJllllifjlBlKt^Q 


ru  talk  about  why  STARS  is  doing  demonstration  projects;  what  we  sec  as  demonstration  projects; 
how  we  plan  to  identify,  select,  and  nm  the  demonstration  projects;  and  where  we  are  in  mis  process 
today. 


STARS  Demonstration  Projects 

Motivation 


Show  the  value  of  Megaprogrammiug:  a 
Process-drivejiy 

Domain-specific  Reuse-based, 
Technology-supported, 

Collaborative  Developmejit 
software  engineering  paradigm  on  DoD  systems 


As  you  have  seen  from  earlier  presentations,  STARS’  vision  is  that  megaprogramming  is  an  emerging 
new  software  engineering  paradigm  and  that  the  STARS’  mission  is  to  accelerate  the  adoption  of  mega- 
programming  concepts  and  technologies  within  the  DOD  community.  The  strategy  STARS  has  adopted 
to  achieve  this  mission  is  thiecfol±  ensure  the  basic  technologies  and  capabilities  are  available  to  sup¬ 
port  employing  the  megaprogramming  paradigm,  show  that  the  megaprogramming  paradigm  can  be 
used  successfully  on  DOD  systems,  and  to  provide  transition  support  to  reduce  the  risks  of  adopting  the 
megaprogramming  paradigm. 


The  demonstration  projects  primarily  support  the  second  part  cf  this  s^  a^egy  by  applying  the  megapro- 
gramnrting  paradigm  to  some  actual  DOD  systems. 


STARS  Demonstration  Projects 

Motivation 


Reduce  adoption  risks  in  DoD’s  evolution  to  Megaprogramming 
software  engineering  paradigm  through: 

•  case  studies  of  success  stories 

•  lessons  learned 

•  quantification  of  benefits 


llie  dcmonstraiion  projects  also  support  the  dtird  part  of  the  strategy  by  providing  the  opportunity  to 
document  with  case  studies  the  qjplication  of  the  megaprogramming  approach  to  seme  actual  DOD 
systems,  collect  lessons  learned  in  transitioning  to  and  applying  megaprogramming,  and  quantify  some 
of  the  benefits  of  using  the  megaprogramming  approach. 


60 


STARS  Demonstration  Projects 

Motivation 

Support  the  maturation  of  capabilities  needed  to  support 

Megaprogranuning  paradigm 

•  understand  issues  of  transition  to  megaprogramming  approach 

•  feedback  from  demonstration  projects  l  d  to  refine  capabilities 

•  “tested"  commercial  technology  base 

nwinuTHf  ^lllJll^,ll|•ft— iiifVCS 


The  demonstration  projects  also  support  the  first  part  of  the  strategy  by  providing  an  opportunity  to  test 
many  of  the  megaprogramming  technologies  in  the  context  of  a  real  DOD  application.  The  feedback 
provided  by  the  demonstration  projects  will  help  in  refining  these  technologies  and  tools  so  that  more 
mature  capabilities  'will  be  available. 
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STARS  Demonstration 

What 


Demonstration  Projects: 

•  Software  intensive 

•  Process-driven,  Domain-specific  Reuse-based,  Technology-supported 
software  paradigm 

•  Actual  DoD  system  or  subsystem 

•  Developed  by  Govt/Contractor,  not  STARS  program 

•  Use  STARS  technology 


Our  goal  is  to  demonstrate  the  value  of  the  megaprogranuning  paradigm  on  actual  DOD  systems.  In 
order  to  have  a  credible  demonstration  and  to  understand  the  transition  issues,  the  actual  developer 
needs  to  be  separate  from  the  STARS  program.  It  could  be  an  in-house  government  organization  or 
DOD  contractor.  Over  the  last  couple  of  years,  the  STARS  program  has  developed  teclmologies 
capabilities  to  specifically  support  the  megaprogramming  paradigm.  Most  of  these  c^abilities  wil 
embodied  in  a  Software  Engineering  Environment  (SEE)  that  each  STARS  Prime  connactor  is  ass 
bling.  These  SEEs  and  other  STARS  developed  technologies  will  be  used  in  die  demonstration 
projects. 
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STARS  Demonstration 

What 


Commercial 

Counteipaits 


STARS  technical  work  on 
proce&s,  reuse,  technolo¬ 
gy  support,  collaborative 
development 


STARS  Demonstration 
SUppon  team 
& 

Demonstration  Project 
team 


Demonstration  Project 
esvaonments 


Vendors 


This  chart  shows  some  of  the  reladonships  involved  in  patting  together  the  SEE  that  will  be  used  in  the 
demonstration  projects.  Each  STARS  Prime  contractor  has  a  commerical  cotmterpart  that  will  supply 
the  basic  underlying  framework  for  the  SEE  Most  of  the  tools  integrated  with  the  SEE  will  be  provided 
by  commercial  CASE  tool  vendors.  STARS  will  provide  some  special  purpose  tools  and  integrate  all 
the  pieces  to  provide  and  integrated  SEE  for  each  demonstration  projea  to  use. 
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STARS  Demonstration  Projects 

How 

Select  “appropriate”  DoD  projects  (3) 

Prepare  projects  to  use  Megaprogramming  concepts  and 

technologies 

Develop  system  using  Megaprogramming  approach 

Capture,  analyze,  and  publicize  results 

The  overall  process  for  doing  the  demonstration  projects  is  outlined  here:  selecting  appropriate 
projects,  preparing  each  project  for  the  demonstration,  developing  the  demonstration  project  applica¬ 
tion,  and  capturing  the  results.The  next  chart  shows  a  timeline  for  these  activities  and  the  steps  are 
described  in  the  following  slides. 
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STARS  Demonstration  Projects 

How 


Created  Demonstration  Joint  Activity  Group  (D  JAG) 

Representatives  from: 

•  STARS  program 

•  STARS  Prime  contractors 

•  Services 

Responsible  for: 

•  selecting  and  recommending  demonstration  projects 

•  developing  a  concept  of  operations  for  the  demonstration  process 

•  monitoring  the  demonstration  projects 

•  reporting  on  the  results  of  the  demonstration  projects 


n  iifiiiii  hij  iii^wVGlO 


In  Older  to  plan,  select,  and  oversee  the  demonstration  projects,  a  working  group  (DJAG)  widi  repre¬ 
sentatives  from  the  STARS  program,  STARS  Prime  contractors,  and  the  Services  was  formed.  The 
DJAG  is  responsible  for  doing  the  project  selection  activities,  doing  the  high  level  program  planning 
for  the  demonstradon  projects,  monitoring  the  demonstration  projects  as  they  are  conducted,  and 
reporting  on  the  results  of  demonstration  projects. 


STARS  Demonstration  Projects 

How 


“Ideal”  projects: 

•  size  sufficient  to  be  valid  demonstration 

•  schedule  compatible  with  STARS 

•  organization/management  receptive  to  change 

•  willing  and  able  to  utilize  new  technology  and  processes 

•  domain  appropriate  for  architecture-based  reuse 

•  reuse  assets  exist  or  can  be  obtained 

•  organization  has  software  process  awareness 

•  security  classification  won’t  get  in  way 

•  Ada 


We  are  currently  in  the  process  of  identifying  candidate  demonstration  projects.  These  are  some  of  the 
traits  of  the  “ideal”  demonstration  project 

A  project  should  be  large  enough  that  prograniming-in-the-large  is  demonstrated.  We  are  looking  for 
projects  that  would  require  in  the  range  of  16  to  20  software  engineers  over  a  24  month  period. 

The  schedole  for  the  project  must  be  compatible  widr  ours.  The  developing  organization  must  be  able  to 
interact  with  STARS  beginning  early  in  FY93  to  get  prepared  for  applying  the  megaprogramming  par¬ 
adigm  to  the  project  The  demonstratiem  project  development  should  begin  early  in  FY94  and  complete 
by  early  FY96. 

Adopting  the  megaprogrammmg  paradigm  will  require  a  cultnral  change  in  the  development  organiza¬ 
tion  that  can  only  effectively  take  place  if  that  organization  fully  supports  the  change.  Included  in  this 
change  is  the  adoption  of  the  SEE  supplied  by  the  STARS  Prime  associaad  with  the  demonstration 
project 

Domain-specific  reuse  is  a  key  element  of  the  megaprogramming  paradigm,  so  the  demonstration 
project  must  be  in  a  domain  appropriate  for  domain-specific  reuse  and  a  set  of  domain-specific  reusable 
assets  should  be  available  to  use  in  the  demonstratioD  project 

Another  key  component  of  the  megaprogramming  paradigm  is  software  process.  The  develpment  orga¬ 
nization  should  have  a  process  awareness  and  a  documented  software  process. 

One  of  the  major  goals  of  these  demonstration  projects  is  to  provide  success  stories  of  adopting  and 

D  using  the  meganrogramming  paradigm  on  actnal  DOD  applications.  Therefore,  we  want  to  work  with 
projects  that  can  allow  the  results  to  be  made  available  openly  and  that  wiU  be  able  to  talk  about  their 
experiences  openly. 

The  project  should  be  an  Ada  project. 
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STARS  Demonstration  Projects 

How 


Prepare  project: 

•  Establish  organization  baseline 

•  Educate  project  personnel  in  Megaprogramming  concepts 

•  Enhance  project  process  to  incorporate  reuse 

•  Instantiate  tailored  SEE  for  project 

•  Incorporate  reuse  assets  into  SEE 

•  Incorporate  project  processes  into  SEE 

•  Train  project  personnel  on  SEE,  process,  and  reuse  mechanisms 

•  Pilot  developments 


When  a  “promising”  project  has  been  identified,  we  will  then  see  if  we  can  form  a  partnership  with  that 
projert  to  “craft”  a  demonstration  project  that  meets  both  STARS’  and  the  project’s  objectives.  Once  a 
partnership  has  been  formed,  STARS  will  then  begin  preparing  the  project  to  adopt  the  meg^rogram- 
ming  para^gm.  The  initial  steps  of  this  phase  will  be  to  ^ucate  the  development  organizaricn  person¬ 
nel  in  megaprogramming  concepts  and  to  baseline  the  development  organization  in  terms  of  process 
maturity,  prodoctivity,  and  quality.  After  understanding  the  development  organization’s  software  pro¬ 
cess  and  supporting  tools,  STARS  will  worit  with  the  development  organization  to  incorporate  reuse 
into  their  software  process  and  to  determine  the  tool  suite  needed  in  their  SEE.  The  SEE  will  dien  be 
as.  mibled,  the  modified  software  processes  will  installed  in  the  SEE,  the  reuse  assets  incorporated  in 
the  SHE,  and  integration  testing  p^oimcd  on  the  SEE  Development  organization  personnel  will  be 
trained  in  the  use  of  the  SEE,  process,  and  reuse  mechanisms.  The  develpment  organizaticn  may  then 
do  some  small  pilot  projects  to  refine  their  software  process  before  startins  die  demonstration  project. 
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STARS  Demonstration  Projects 

How 

Develop  application  using  Megaprogramming  approach: 

•  Project  uses  Megaprogramming  concepts  supported  by  STARS 

technology  to  develop  system 
•  STARS  provides  assistance  and  monitors: 

-  provide  on-site  supoort 

-  gather  and  analyze  data  on  usage 

-  refine  SEE,  process,  and  reuse  mechanisms 

-  leverage  lessons  learned  across  projects 

Drat, ■mum  ?wy»»BM»VGU 


As  the  development  organization  works  on  the  demonstraton  project,  die  STARS  Prime  associated  with 
the  demonstration  project  will  provide  on-site  support  to  the  development  organization  and  monitor 
how  the  projea’s  usage  of  the  megeprogramming  paradigm  is  going.  The  STARS  Prime  may  assist  the 
development  organization  to  refine  their  processes  and  may  tune  the  SEE  to  better  suppon  the  demon¬ 
stration  project  As  things  are  learned  in  one  demonstration  project  that  may  benefit  others,  they  will  be 
spread  to  the  other  ir'ijects. 
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STARS  Demonstration  Projects 

How 


Captiire,  analyze,  and  publicize: 

•  Gather  data  from  demonstration  projects 

•  Determine  impact/benefits  of  Megaprogramming  approach 

•  Compile  lessons  learned  about  transitioning  to  and  applying 
Megaprogramming  concepts 

•  Disseminate  results  to  community 


Before,  dating,  and  afterwards  data  will  be  collected  from  the  development  organization  for  the  demon* 
stradon  project.  Daring  the  demonstration  project  this  data  will  be  osed  to  determine  how  well  the 
megaprogramming  paradigm  is  working  and  to  make  nhd-conrsc  corrections  if  necessary.  At  the  com¬ 
pletion  of  the  demonstratioa  projects,  the  information  will  be  compiled  into  lessons  learned  about  tran¬ 
sitioning  to  and  t^lying  the  megaprogramming  paradigm,  and  to  determine  the  impact  of  using  the 
megaprogramming  paradigm.  These  will  be  put  into  reports  that  will  be  made  availk^le  to  tire  DOD 


community. 


STARS  Demonstration  Projects 

Status 


The  DJAG  is  currcndy  conccntranng  on  project  seieciion.  We  have  initiated  activities  with  each  of  the 
Services  to  identify  good  candidate  projects  and  expea  to  finish  this  activity  by  the  end  of  this  fiscal 
year  with  agreements  for  three  demonstration  projects.  In  parallel  to  this,  we  are  developing  an  overall 
plan  for  the  demonstration  process  that  wiU  define  the  demonstration  process,  identify  the  data  to  be 
coDected  doting  the  demonstration  projects,  and  describe  how  the  data  wall  be  analyzed  and  reported. 
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This  session  is  designed  to  enlist  year  help  in  looking  for  potential  baniers  to  the  adoption  of  the 
Meg^Tiogtamzning  paradigtn 


And  to  s&Bt  some  disctission  of  possibie  cantedve  methods  that  might  be  used  for  risk  rednetioa. 
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TR.\.NsrnoN 

FORMAT  OF  SESSION 


Reus* 

Corrent  strategr 
Oiscnssioo  of  adoptioo  risks 

Process 

Correat  strategy 
Dtscnssion  of  adoption  risks 

Software  Eagiaeering  Enrirotaseat 
Cnrrent  strategy 
Discussion  of  adoption  rsiks 


The  format  to  be  used  in  this  session  is  slightly  differait  than  other  sessions.  What  I  am  going  to  do  is 
break  our  4S  minates  (of  briefing  and  questions)  into  3  segments.  Each  segment  (tease,  process  and 
eavironmem)  wiT  start  with  a  brief  innod action  of  the  current  approach  that  STARS  is  following  in  this 
particular  technical  transfer  area.  Then.  I  will  moderate  an  8  minute  discussion  period  on  other  risks  that 
the  audience  thinks  are  important  and  sohdt  some  methods  to  reduce  that  risk.  The  discussion  will  be 
recorded  in  outline  form  as  we  go  along.  We  will  repeat  this  for  each  of  the  3  segments.  Following  that, 
there  win  be  a  few  minme<  to  discuss  any  issues  that  did  not  fix  into  these  3  areas. 


You  will  see  this  template,  of  the  four  sansition  steps  that  STARS  is  usi  « to  introduce  new  ideas  into  an 
orsanizadon's  sofnt  are  development  environment,  on  each  of  the  3  approaches  that  I  explain.  The  template 
represents  stages  of  tnanmty  for  the  inoodoctiOD  of  new  methods  into  an  organization.  On  the  left,  the  new  ideas 
are  being  prototyped  in  in  ad  hoc,  limited  manner.  As  you  decide  that  this  is  a  good  method  that  deserves  wider 
ose.  you  stan  to  matnre  the  method  by  evolving  the  snpporting  technology  and  by  managing  the  organizational 
change  caused  by  the  introductioa  of  the  new  method.  This  is  an  iterative  cycle,  of  technology  evolonon  and 
cultural  change,  which  may  take  several  rounds  before  the  method  becomes  widely  accepted  by  the 
crgatuzauoQ.  Once  this  acceptance  ooctits,  the  method  becomes  instiinoonalized  with  a  broad  base  of  usage. 


76 


TECHNOLOGV  TRANSITION 

STARS  REUSE  APPROACH 


CApabil^  :o  rcchant* 
<seS  acrass  nbnnes 
'  Imefration  with  S££s 
Processes  and  toois  to 
suaoon  aset  creaaon. 
tffeiaaaon  ano 
manactmertt 


•  CataNn  changes  tn 
acc>^Bit)on  stTJca^re 

•  Reuse  adoptsoe 
haneteok 

•  Giobtijnes  on  rntegrst* 
in(  reiae  into  omJ 
wTf  at  aoif%  duurwss 

•  Tailored  sotNrare 
de«reioor*rt  pan 

•  CARDS  reuse 
•ttuepnrts* 

•  Anaiyzarpubljcce 

canes  and 
lesBm  teamed 


For  the  STARS  Reuse  area,  the  approach  to  technology  transfer  that  is  being  taken  consists  of  sorting  with 
prototNpe  reuse  Ubrants.  such  as  CAMP  and  RAPID,  and  the  initial  STARS  repository  technology.  This  is  being 
evolved  into  2nd  generation  reuse  libraries  build  around  an  open  arcbiiecutre  frameworic  so  that  organizations 
can  impleroent  libraries  on  multiple  platforms.  These  libraries  will  be  integrated  into  their  envimnineots. 
Processes  are  being  developed  to  help  organizauens  manage  reusable  asses. 

The  cultural  impact  is  being  reduced  by  the  early  introduction  of  the  concept  of  software  component  rense  with 
guidelines  on  bow  a  company  can  develop  retssfc'e  asses  as  a  busioess  strategy.  Changts  to  acquisition  policy 
are  necessary  to  eccoorage  this  trend.  Blueprins  for  reuse  libraiies  are  being  developed,  e.g..  by  CAPJDS,  and 
success  stories,  of  the  bene5s  to  projecs  of  domg  reuse,  are  being  publicized. 

The  STARS  effen  will  measam  the  bcnefis  of  reusable  asses  as  a  business  strategy  during  the  3  demonstradon 
projecs,  starting  m  October  1993.  Ths  will  be  followed  by  commercialization  of  this  technology  to  wide 
spread  use. 
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TR.\.\srnoN 

REUSE  ADOPTION  RISKS? 


Now  we  have  aboot  8  minnaa  fcr  discussion  of  some  areas  tbat  yon  feel  are  important  adoption  lisks  for  os  to 
consider.  I  will  moderate  die  discnssioa 


Some  potential  risks  ate  incloded  here,  as  samples,  to  give  you  some  ideas  for  discussion: 

•  Acquisition  policy  (benefit  from  reusing,  shift  to  manage  families  of  systems) 

•  Investments  in  application  domain  .'schitectnres  and  components 

•  Change  Management 

•  Dichotomy  of  community  consensus  on  architecture  vs  company  compedtrve  advantage 

•  Lack  of  reuse  base  and  praaical  experience 

•  Lack  of  market  size 
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TECHNOLOGY  TRANSmON 

ST.4RS  PROCESS  APPROACH 


/S - ^ 


Point  ^1  ~  inology  1 

Cultural  . 

InstiuticnaJ-  - 

Solutions  Evolution  '  j 

1 

Impact  •  ■ 

c> 

•  Ccnctpt  yct3t>rrs 

•  WtfTCty  4nd  eocy- 
rr«nt  exsere^ce- 
tested  iSTAW 
processes 

•  madeiirf 
ooer-'arta 

•  ervacbon 
cxpcnm^na 


Ubnry  of  fiindarrwntai 
pmott  assets 
CjdabUir/  to  compose  a 
sci^«».  -re  process  from 
reusaE>l<  process  assets 
Capaotlfty  to 
syppoft  tr*  gertorrv 
axe  axt  measurement 
of  a  defined  process 


•  GyiOeiifies  and  techniques 
tor  process  ddinitton  and 
measurement 

•  Guiddif^  for  taitonnt 
process  to  specific 
development  standards 
and  acqutSiOon  policy 

•  Identify  and  publidze 
cost  penefTt  models 
tor  process-dmren 
development 


•  Successful  demoTH 
stratons  cJ  process 
definition  arto  man- 
aggoenton  OoO 
prefects 

•  Commercial 
tecnnoicortor 
process  cennttion 

•  Integrated  SEE 
support  tor  process 
marugement 


TtrfcMlnp  tmmmmjnamjyC? 


The  technology  transfer  approach  for  process  starts  with  the  work  that  the  Software  Engmeering  Tncrimri.  and 
others  have  done  to  identify  and  document  experietjce-testcd  software  processes.  Also,  various  process  modeling 
and  process  measurement  expeximeots  have  been  conduaed,  snch  as  the  Arcadia  project  at  the  Umveisity  of 
Southern  California. 

This  base  is  being  evolved  by  STARS  to  construct  a  Process  Asset  Library  of  experience- tested  software 
processes.  The  capability  will  be  present  to  suppesrt  measurement  and  pcrfoimancc  analysis  of  process 
components.  This  wUl  provide  soppon  for  early  anempts  at  Statistical  Process  Control  of  software  processes. 

The  Process  Asset  Library  will  evenmally  have  the  capability  to  compose  new  software  processes  from  reusable 
pocess  assets. 

Since  this  is  a  relative  new  subjea  for  industry  (the  Software  Engineering  Process  Group  is  the  closest  COTcept 
today),  guidelines  and  techniques  for  process  definition,  tailoring,  measurement  and  management  will  be 
developed  co  aid  busmesses  in  improving  their  software  development  pmr^.w^ 

The  cost  becefis  of  process-driven  development  wUl  be  determined  rfiTring  tfae  demonstration  projects. 


TECHNOLOGY  TRANSmON 

PROCESS  ADOPTION  RISKS? 


Some  potential  risks  sre  mclud»i  beie,  as  samples,  to  give  you  some  ideas  for  discnssion: 

•  How  do  process  engineers  appear,  get  ttauied  and  operate  in  organizations? 

•  How  do  we  prevent  process  engineers  &om  appearing  as  excess  staff.  like  Configuration  Management  and  Quality 
Assurance  bare  been  treated  in  past? 

•  DoD  STD2167A  is  document  driven  vice  process  driven.  Will  it  get  in  tbe  way,  like  it  has  for  parallel  development 
in  *baild$’  or  Ada? 


•  How  maturity  do  organizations  need  to  be  before  benefiting? 

•  Increased  investment  in  training  and  education 

•  Lack  of  Policies  (e.g.,  metrics-.) 

•  Can  we  gki*  the  concept  of  process  metrics  (which  industry  has  been  struggling  with  for  some  time)  and  expand  it 
into  tbe  next  generation  concept  of  process  definition  with  automated  measurements? 
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TECHNOLOGY’  TRANSITION 

STARS  SEE  APPROACH 


Point 

Solutions 


•  Fr»tT5*won<-b«ed 
S££  ‘^-bcCs 

•  Piotayv* 
ifTfanrjticn  models 


Technolosy 

Evolution 


•  ScsUbleooen 
tKfuteaun 

•  Tool  ooObHity 
cxoenments  juoss 
mul&ple  fTamewOfv- 
based  S££s 

•  Evaluate  !ool-to-tool 
uttoopuabiuty 

•  InUfration  d  pmeess 
and  reuse  meenanIsTO 

•  Exsiore  (ramei»on<- 
to-tTame.vort< 
intsroperaOiiity 


Cultural 

Impact.' 


•  Gudelines  and 
tecnniducs  for  e(tendit\( 
care  services 

•  Guidelines  tor  adoponf^ 
taiiomt  .vr<  to  aoplica- 
Oon  dornamVproiecis 

•  IdenCfy  and  publicze  cost 
benefits  at  tameiniortr- 
based  aporaacti 


Initituxior-a!- 


c  Succesdul 
demoRsS  rtlon  ct 
ftamewcrV-based 
apcnacb 

•  Cotrjneroal  tecbnol- 
oo  for  instanbabng 
tramewocit-based 
SEES 

•  rrameworksas 
part  of  eammerciai 
platform 


TeSniViny  SwueaklftaM/Vtie 


Wotk  on  prototype  &amewoiks  and  initial  infoimanon  models  are  being  expanded  to  open  architectmes  which 
will  allow  cnvironmeno  to  bs  sized  to  the  project  and  for  tools  to  be  moved  from  one  cnvironmem  to  another. 
This  is  the  delivery  vehicle  for  the  process  and  reuse  technology.  For  the  first  nine,  process  and  reuse  aspects 
will  be  integrated  into  the  environmeu. 

Guidelines  will  be  produced  so  that  businesses  can  adapt,  and  tailor,  the  Software  Engineering  Environment  for 
theii  application  domains  and  projects.  Anotbs'  imponant  cultural  impact  area  to  be  addressed  is  how  to  capture 
legacy  processes,  from  your  organization,  into  the  new  environment.  Giridelines  will  be  developed  on  successful 
ways  to  do  this. 


Gimmerdal  components  will  be  used,  by  the  Commercial  Counterparts,  u>  develop  the  enviromneoL  Successful 
demenstnrion  of  frameworic-based  environments  will  aid  in  their  comraeroial  acceptance. 


Some  potential  mis  are  included  here  to  give  you  soise  ideas  for  discussion.' 

•  How  will  legacy  toob,  which  represent  investmems  soil  oa  the  booits,  be  included  in  the  new  environment? 

•  The  leveb  of  investment  in  software  toob  has  never  been  very  high  considering  the  complexity  of  the  task. 
Other  complex  tasks,  snch  as  mechanical  design  (wthcb  have  been  automated  using  Computer  Aided  Design) 
and  shop  Qoor  tooling  (which  have  been  automated  using  numerical  control),  have  seen  large  invesunents 
because  management  perceives  that  the  job  can  be  done  mere  cost  effective.  How  can  thb  pere^oon  be  changed 
for  software? 
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TECHNOLOGY  TRANSITION 

ADOPTION  RISKS  SUMMARY 


•  An  approach  has  been  described  for  each  of  the  3  STARS  technology 
areas  (reuse,  process,  and  environment) 

•  Through  group  discussions,  we  have  identified  other  potential  adoption 
risks  areas 

•  This  additional  insight  will  greatly  assist  STARS  in  reducing  the 
adoption  risks  for  Megaprogramming 


An  approach  ertechaoiogy  transfer  has  been  described  for  each  of  the  3  STARS  technology  areas  (reuse, 
process  and  envirounent).  Through  group  discussions,  we  have  identified  other  potential  adoption  lislcs 
areas.  This  additional  insight  will  greatly  assist  STARS  in  redndng  the  adoption  risks  for 
Megaprogramming. 

The  discussion  can  cononne  daring  the  breaks  with  all  of  os,  or  at  a  larw-  time. 

Thank  yon  for  yotir  ideas.  For  farther  infbnnahoQ,  contact; 

Dr.  Jerry  R  Pixtao,  412-268-3656.  jpixton@seLcmu.edu 
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TECHNOLOGY  TRANSITION 

REUSE  ADOPTION  RISKS? 


•  Acquisition  policy  (benefit  from  reusing,  shift  to  manage  families  of 
systems) 

•  Investments  in  application  domain  architectiires  and  components 

•  Change  Management 

•  Dichotomy  of  cominunit}’  consensus  on  architecture  versus  company 
competitive  advantage 

•  Lack  of  reuse  base  and  p^-actical  experience 

•  Lack  of  market  size 


TECHNOLOGY  TRANSITION 

PROCESS  ADOPTION  RISKS? 

•  How  do  process  engineers  appear,  get  trained  and  operate  in 

organizations? 

•  How  do  we  prevent  process  engineers  from  appearing  as  excess  staff, 
like  Configuration  Management  and  Quality  Assurance  have  been 
treated  in  past? 

•  DoD-STD-2167A  is  document  driven  vice  process  driven.  Will  it  get  in 
the  way,  like  it  has  for  parallel  development  in  “builds”  or  Ada? 

•  How  mature  do  organizations  need  to  be  before  benefiting? 

•  Increased  investment  in  training  and  education 

•  Lack  of  Policies  (e.g.,  metrics  . .  .) 

•  Can  we  take  the  concept  of  process  metrics  (which  industry  has  been 
struggling  with  for  some  time)  and  expand  it  into  the  next  generation 
concept  of  process  definition  with  automated  measurements? 


VmmmmJfimmJyCli 


TECHNOLOGY’  TRANSITION 

SEE  ADOPTION  RISKS? 


•  How  will  legacy  tools,  which  represent  investments  still  on  the  books, 
be  included  in  the  new  environment? 

•  Tne  levels  of  investment  in  software  tools  has  never  been  very  high 
considering  the  complexity  of  the  task.  Other  complex  tasks,  such  as 
mechanical  design  (which  have  been  automated  using  (Computer  Aided 
Design)  and  shop  floor  tooling  (which  have  been  automated  using 
numerical  control),  have  been  large  investments  because  management 
perceives  that  the  job  can  be  done  more  cost  effective.  How  can  this 
preception  be  changed  for  software? 
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TECHNOLOGY  TRANSITION 

MEGAPROGRAMMING  ADOPTION  RISKS? 


•  Are  there  other  activities  going  on  that  could  help,  or  accelerate,  the 
adoption  of  Megaprogramming? 

•  Demonstration  projects? 

•  Technology  transfer? 
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CARDS  REUSE  BLUEPRINT 

OVERVIEW 

•  Blueprint  concept 

•  CARDS  network  structure 

•  Reuse  adoption  handbooks 

•  Technology  transfer  initiatives 

•  Summary 

Mmm 

This  presentation  disensses  the  blnspnnt  for  domam-spedfic  rense  being  developed  the  CARDS  (Central  Archive 
for  RensaWe  Defense  Software)  program  tmder  the  pmview  of  the  USAF  Electronic  Systems  Division  (ESD)  and  the 
STARS  program.  We  will  disenss  the  oonoept  of  the  ‘Imowledge  blnepxint”  for  reuse;  the  physical  smiuute  of  the 
prototype  tense  libtaiy  that  serves  as  a  base  for  validation  of  the  blueprint;  the  set  of  rense  adoption  handbooks  that 
fonn  the  heart  of  the  blueprint;  the  other  technology  transfer  initiatives  being  undertaken  by  CARDS;  and,  finally,  a 
summary  of  die  CARDS  blueprint. 
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CARDS  REUSE  BLUEPRINT 

THE  BLUEPRINT 


CARDS  is  responsible  for  production  of  a  blueprint  for  domain  specific 

reuse 

This  blueprint 

•  Is  a  plan  of  action  for  instituting  domain  specific  reuse  into  an 
organization 

•  Is  constructed  as  a  ‘profile,”  organizing  the  information  and 
referencing  other  documents  for  the  detail 

•  Contains  instructions  on  tailoring  general  processes  and  environments 
for  use  in  a  domain  specific  reuse  oriented  environment 

•  Is  to  be  transferred  to  a  variety  of  programs  to  start  them  into  domain 
specific  reuse  with  limited  initial  investment 


CAKOS 


The  prmuiy  mission  of  CARDS  is  to  develop  a  “knowledge  blueprint*  for  domain-specific  rensc. 
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Cards  has  tbre«  main  goals 

0  Devtlop  a  prototype  libiaty  for  the  commaTid  center  domain  as  a  testbed  for  the  reuse  concepts 
o  Develop  a  *^o«ledge  blueprint”  for  domaa-^>eciSc  reuse 
o  Develop  a  traming  plan  to  teach  domain-specific  reuse  to  others 

The  prototype  library  ■work  is  developing  a  set  of  documents  that  describe  the  process  of  seniag  up  and  populating 
this  library.  These  documents  can  be  used  by  others  interested  in  setting  up  domain-specific  reuse  ISnaries. 

The  knowledge  bhiepnnt  is  made  up  of  docnments  describing  the  whole  process  of  introdudng  and  making  effective 
use  of  domain-spedfic  reuse. 

The  training  portion  of  the  project  is  explicitly  tasked  with  teaching  domain-specific  reuse  to  others. 
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(Reuse  iibraiy  Interoperability  Gicmp),  miiveisities,  etc.  These  inihal  concepts  have  been  used  in  setting  up  a 
prototype  (loinam-^>ecifk  Ubraiy  for  Command  Centers.  Through  mtemction  among  the  blnepiint  developers,  the 
prototype  library,  and  the  eommant:  center  program  at  ESD,  the  blneptint  is  refined.  The  ^Tototype  libiaiy  is 
reaching  out  to  other  command  center  programs  in  order  to  achieve  a  consensus  on  the  structure  and  contents  of  a 
command  center  tense  library. 

A  main  goal  of  the  blueprint  is  to  transfer  the  technology  learned  via  its  development  into  other  programs. 
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o  Central  Ubrauy  management  and  maintenancr.  site  in  gairmont.  WV 
o  Four  initial  remote  acxess  sites,  accessing  the  libiaiy  via  Internet 

o  Can  be  rattended  to  more  sites  as  desired;  additional  tiial  nsers  for  the  command  center  rense  libraiy  are  solicited 
o  Access  to  libiaxy  is  identical  at  all  sites 

o  Places  access  to  libraiy  at  the  j5ngeit^  of  the  command  center  developers 

o  Cooperating  with  ASSET  libraiy  in  espenments  on  libraiy  component  inteicbange  and  interoperability 
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CARDS  REUSE  BLUEPRINT 

REUSE  ADOPTION  HANDBOOKS 


Blueprint  is  to  be  packaged  as  a  series  of  reuse  adoption  handbooks 


•  Modeled  after  SEI  Ada  Adoption  Handbook 

•  Addresses  the  Needs  of  various  blueprint  user  communities 

-  Direction  level  staff 

-  SPO  legal,  contracting,  program  management 

-  SPO  engineers  and  system  houses 

-  Component  developers  (industry  and  government)  &  reuse  and 
process  tool  providers 
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The  heart  of  the  bicrwiedge  bhieprint  for  domain-specific  reuse  is  a  scries  of  Rcose  Adoption  Handbooks.  They  are 
modeled  after  the  Ada  Adoption  Handbex*  produced  by  Carnegie  Mellon  University’s  Software  Engineermg 
Institute. 

In  order  for  reuse  to  become  wide^tread,  vaiioos  groaps  of  people  will  have  to  be  convinced  of  its  advantages  and 
taught  how  to  implement  it.  These  handbooks  will  address  the  issues  from  the  perspective  of 

0  Dircoion  level  staff,  who  oversee  many  programs 

0  Contraoing  and  program  management  personal,  who  will  be  issning  RTF’s  for  ^jedfic  programs 
o  Engineers  who  will  be  performing  contneu  mvotving  reuse 
0  Component  developers,  who  will  develop  assets  that  will  be  reused,  and 
0  Tool  vendors,  who  will  provide  sofrware  tools  to  aid  the  reuse  process. 


CARDS  REUSE  BLUEPRINT 

HANDBOOK  COInTEOTS 


Blueprint  subject  areas  addressed  across  the  handbooks  are: 

•  Process  — drives  all  other  aspects  of  the  blueprint:  how  the  process 
alTects  each  level 

•  Acquisition  — system  acquisidon  rules  that  have  significant  effect  on 
reuse 

•  Benefits  — investment  costs  and  expected  return  on  investment  for 
reuse  for  each  level 

•  Training— what  training  is  required  for  this  level  to  effect  a  reuse 
program 

•  Security— protection  of  secure  components  in  the  recommended  reuse 
environment 

•  Consensus- obtaining  muiti-organizationai  consensus  on  domain 
models 

CAKDS  lUc.  Ill  ifmtiftbmOVi 


Ttes  are  several  issues  that  cut  across  several  of  the  ^SSercat  categories  of  people  involved  with  reuse,  and  will 
thus  be  addressed  in  several  of  the  Handbooks. 

0  Process— afieos  all  categories 

0  Acquisitioa— dhrectkin,  acquisition,  ano  engmeets  are  all  affeaed  bjr  rules  that  encourage  or  discourage  reuse 
0  Benefits— all  categories  need  to  know,  ‘'What’s  in  it  for  me?” 

0  Security— dnection  level  and  program  managers  want  to  be  assured  their  programs  are  secure;  enginreis  and  tool 
vendors  have  to  know  bow  to  ensure  the  security 

0  Consensus— all  those  involved  must  reach  consensus  on  reuse 
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CARDS  REUSE  BLUEPRINT 

DEFECTION  LEVEL  HANDBOOK 


Direction  level  staiff:  those  with  responsibility  for  multiple  programs  in  an 
application  domain 

Handbook  enables  direction  level  staff  to  make  intelligent  decisions  on 
whether  and  how  to  implement  reuse  in  their  domains 

•  Explains  domain  specific  reuse  in  direction  level  terms 

•  Explains  costs  and  benefits 

•  Provides  question/answer  format  to  enable  them  to  get  started  in  reuse 

•  Provides  guidance  of  how  reuse  and  rapid  prototyping  could  be  used  to 
assist  in  definitizing  user  requirements 


CIKOS  »Bm  SiMfMfaartyOf 


The  (iirection  level  handbook  addresses  reose  issnes  from  Uie  perspective  of  people  who  oversee  many  programs. 
They  are  in  a  position  to  foster  reuse  and  also  stand  to  gain  a  lot  wim  the  adoption  of  reuse.  A  single  program, 
because  of  the  addeo  expense  and  aggravation,  may  resist  developing  components  that  c?n  be  used  by  other 
programs,  but  a  director  can  see  the  cverali  benefits  across  pmgrani<. 
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CARDS  REUSE  BLUEPRINT 


ACQUISITION  HANDBOOK 


Enables  DoD  personnel  to  structure  RFPs  and  contracts  to  facilitate 
re:  ’  and  provide  overall  cost-savings  and  quality  increases  for  DoD 

•  Builds  on  and  extends  STARS  task  in  acquisition  issues 

•  Directly  addresses  contracting/licersing  guidance 

•  Identifies  incentives  to  motivate  reuse 

•  Provides  guidance  in  constructing  RFPs  so  as  not  to  preclude  reuse 
and  in  evaluating  RFPs  and  contract  performance  with  reuse  in  mind 

•  Explains  costs  and  benefits  from  a  single  program  life-cycle  perspective 

•  Training  classes  available  for  DoD  and  contractor  personnel 

CAKBS Xk  rrii  »  •  -T  -III  rrir 


Many  airreat  RFPs  are  structored  to  actively  disctjora^e  teaso.  Tbis  handbook  will  fiplain  why  tense  is  benefiaal  to 
a  smgle  program  and  how  to  wnte  RFPs  that  cacxjnrage  the  contractor  to  adopt  reuse. 
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CARDS  REUSE  BLUEPRINT 

ENGINEER’S  HANDBOOK 


Enables  contractor  and  DoD  personnel  to  understand  how  to  create  and 

evolve  high-quality,  lower  cost  systems  by  e'uploying  reuse 

•  Recasts  STARS  reuse  CONCPS  in  terms  for  the  engineer 

•  Guides  DoD  and  contractor  in  definitizLzg  requirements  through 
reuse-based  rapid  prototyping 

•  Guides  DoD  and  contractor  in  utilizing  r^:!' sable  assets  to  compose 
systems 

•  Builds  on  STARS  reuse  processes  to  provide  guidance  on  integrating 
reuse  and  domain-specific  concerns  into  the  development  process 

•  Training  classes  available  for  DoD  and  contractor  personnel 

OtitOS  »mm  SlMW'i'f’tunvClJ 


The  engineers  who  are  acnially  canyiag  out  system  development  are  vital  to  the  success  of  reuse;  their  passive 
reststaime  or  lact  of  undemanding  could  sabouge  the  possibility  of  successful  reuse.  This  handbook  aplaius  the 
concepts  and  for  reuse  adoption  by  the  system  devel<  -eis  across  the  entire  life-cycle,  from  requirements 

defmioon  throngh  prototype  to  delivered  system  and  maintenaik' 


o 
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CARDS  REUSE  BLUEPRINT 

COMPONENT  AND  TOOL  HANDBOOK 


Enables  component  developers  and  tool  vendors  to  understand  how  to 
create  reusable  components  and  tools  for  reuse 

•  Guidance  for  developing  reusable  components 

•  Specifies  requirements  for  tools  to  support  reuse-based  system 
development  and  maintenance 

•  Ibqjlains  incentives  for  developing  these  components  and  tools 


CaXU Mmm 

For  rense  to  be  saccessfnl.  oonnnerdal  ressable  components  and  software  tools  that  assist  reuse  will  have  to  be 
readily  available  for  porchase.  This  handbook  informs  potential  vendors  of  the  needs  and  the  benefits  to  them  of 
meeting  those  needs. 
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CARDS  REUSE  BLUEPREST 

TECHNOLOGY  TSANSFER 


The  main  focus  of  the  CARDS  reuse  bluepnnt  is  on  technology  transfer 

•  Reuse  adoption  handbooks  are  the  basis  for  tech  transfer 

-  Reviewer  of  handbooks 

-  Trial  users  of  handbooks 

-  Future  users  of  handbooks 

•  trial  users  are  major  agents  of  technology  transfer 
~  Internal  receptors  and  advocates 

-  Agents  for  reusing  code  from  elsewhere  (that  in  itself  is  transferring 
technology) 


Tbe  piimaiy  miginn  of  CARDS  is  to  leara  about  iqjpiication  of  domain  specific  reuse  through  imploneatatioo  aad 
use  of  a  prototype  Ubnuy.aod  then  to  disseniisate  the  infonnation  as  indely  and  efTecdvety  as  possd>le.  TheReuse 
Adoptioa  Handbooks  are  the  center  of  this  stotegy,  but  not  the  only  aspea  of  tbe  program  addressing  technology 
transfer.  The  trial  users  of  tbe  prototype  itsetf  are  learning  reuse,  and  wiD  be  agents  of  change  within  their 
organiatioiis.  Furthermore,  the  very  act  of  reusing  components  from  other  organiations  is  transferring  technology. 
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CARDS  REUSE  BLUEPRINT 

MORE  TECHNOLOGY  TRANSFER 


•  Working  with  sizable  sample  of  DoD  software  community  regarding 
reuse 

•  Command  center  domain  model  pulls  together  much  knowledge  of 
command  centers  which  can  be  taught  to  others 

•  CARDS  is  looking  for  interested  DoD  command  center  programs  to 
participate 

•  In  early  1992,  CARDS  will  perform  an  initial  assessment  of  software 
domains  across  DoD 

•  Looking  for  candidate  domains  to  be  implemented  in  late  1992  to 
provide  an  additional  validation  of  the  blueprint 

•  Wbridng  with  DoD/CIM  software  reuse  initiative  to  facilitate  reuse 
adoption 


In  atUlrcion  to  the  binepiint  and  the  prototype  Iteaiy  osers,  there  are  other  aspects  to  technology  transfer  by 
CARDS: 

o  We  are  wotting  with  other  DoD  grmps  interested  in  reose 

o  We  are  looting  for  other  interested  command  center  groups  to  participate  with  the  pnxotypr  oommand 
center  library,  and 

o  We  are  lootmg  for  a  second  domain  for  which  to  begm  uspiemeniatioa  of  a  domam-spedfic  library  in  late  1992. 
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CARDS  REUSE  BLUEPRINT 

BENEFITS  OF  BLUEPRINT 


Implements  many  of  the  1991  JLC  San  Antonio  I  Reuse  Panel 

recommendations  for  eliminating  the  barriers  to  reuse  in  DoD 

•  Provides  the  basis  (building  on  STARS)  to  enable  reuse  to  be  treated  as 
an  inseparable  aspect  of  the  overall  software  engineering  process 

•  Provides  recommendations  and  guidance  so  that  the  DoD  can  create 
incentives,  and  eliminate  disincentives  from  its  current  acquisition 
process 

•  Provides  guidance/handbooks  at  various  levels  of  detail  to  enable  DoD 
and  contractor  staff  to  successfully  implement  reuse 


In  atttnms  1991  a  reuse  panel  sponsored  by  the  Joint  L<^i5tics  Command  convened  in  San  Antonio  to  discnss  the 
baztiers  that  are  keeping  reuse  from  being  widely  adopted  within  the  DoD.  The  handbooks  beittg  produced  win 
address  sevenl  of  these  obstacles  (listed  above)  and  enconzage  their  dimmarion. 
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CATiDS  REUSE  BLUEPREST 

SUiVIMARY 


•  The  blueprint,  in  the  form  of  reuse  adoption  handbo\,ks,  will  be  major 
focus  of  technology  transition  for  CARDS 

•  Trial  users  of  handbooks  and  reuse  library  prototypes  will  be  an 
important  influence  on  blueprint 

•  Reuse  library  prototype  available  for  adoption  by  interested  users 

•  CARDS  is  working  with  DoD/CIM  software  reuse  initiative  to  facilitate 
reuse  adoption 


Those  interested  in  portidpating  as  a  trial  user  site  for  the  Command  Center  library,  or  those  from  another  domain 
interes',ed  in  setting  op  a  rense  library  for  that  domain,  should  ccmtact  Mr.  Scanlon  of  USAF  BSD  at  617>377-S4S4. 
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CARDS  REUSE  BLUTIPRJNT 

FURTHER  INFORMATION 


•  C.\RDS  is  lookijQg  for  another  user  site  for  the  command  center  library 

•  CARDS  is  looking  for  a  second  domain  to  verify  the  blueprint 

•  CARDS  is  under  the  direction  of  USAF  Electronic  Systems  Division 

•  For  further  information,  Contact  Bob  Scanlon  at  ESD,  617-377-8484 
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STARS  AFFILIATES  PROGRAM 


STARS  has  established  an  affiliates  prograun.  This  program  provides  an 
opportunity  for  the  software  community  to  participate  in  the 
technology  activities  associated  with  the  STARS  Ingram  and  to  join 
with  STARS  in  accelerating  the  paradigm  shift  to  megaprogramming. 

STARS  afhliates  are  individvial  representatives  of  organizations 
involved  in  software  development  for  the  government,  including 
government  contractors,  universities,  government  agencies,  and 
environment/tool  vendors. 

Three  levels  of  affiliates  have  been  established: 

*  Information  Affiliates:  Information  Affiliates  have  access  to 
information  regarding  the  STARS  program  such  as  newsletters;  are 
included  on  the  STARS  Twailiwg  list;  have  access  to  the  bulletin  board; 
and  may  participate  in  the  monthly  briefings  and  demonstrations  at  the 
STARS  Technology  Center. 

*  Technology  Transfer  Affiliates:  This  level  of  affiliate  is  expected 

to  cooperate  with  the  STARS  program  on  a  consistent  basis  to  aid  in 
technology  transition  to/firom  STARS  and  the  DoD  community. 
Technology  Transfer  affiliates  are  expected  to  appoint  a  single  point 
of  contact  within  their  organization  who  will  participate  actively  in 
technology  exchange  woi^ing  group  meetings.  These  working  group 
meetings  would  be  coordinated  by  STARS  and  wovdd  meet  periodically 
with  network  interaction  between  meetings.  Sub-groups  might  be 
established  to  foois  on  specific  technology  areas.  These  affiliates 
would  become  familiar  with  the  STARS  Program  and  participate  in  all 
working  group  meetings.  They  may  also  be  asked  to  be  alpha  test  sites 
for  new  STARS  products. 

*  Prime  Afiiliates:  A  Prime  Affiliate  works  directly  with  one 

of  the  STARS  Prime  Contractors  (Boeing,  IBM,  Unisys)  in  technology 
activities  relevant  to  the  STARS  Program,  such  as  product  evaliiation, 
technology  transition,  technology  integration,  smd  tool  development 
In  addition  to  participation  in  periodic  workshops  as  described  above. 
Prime  Affiliates  may  also  participate  in  prime  team  meetings.  Joint 
activities  with  any  of  the  Prime  Contractors  are  arranged  directly 
with  that  prime  on  a  case-by-case  basis. 

Participation  in  the  Technology  Transfer  or  Prime  Affiliate  program  will 
require  that  you  complete  an  afiiliates  questionaire  and  sign  a 
non-disdosxxre  agreement. 


Affiliate  -  1 


Labor,  travel  and  trial  iisage  expenses  associated  with  participation 
in  the  affiliates  program  is  the  responsibility  of  each  a£^ate’s 
parent  (sponsoring)  organization.  STARS  provides  meeting 
accommodations  and  network  access. 

If  you  are  interested  in  becoming  a  STARS  Affiliate,  please  indicate 
the  level  of  affiliation  and  address  yotir  request  to  the  STARS 
Technology  Center,  Attn:  Affiliates  Desk,  Suite  400,  801  North 
Randolph,  Arlington,  VA  22203  or  call  (703)  243-8655  or  Email  to 
"affiliates-desk@stars.rosslyn.unis3^.com''. 


Affiliate  -  2 


STARS  AFFILIATE 
NONDISCLOSURE  AGREEMENT 


The  Software  Technology  for  Adaptable,  Reliable  Systems  (STARS)  program  is 
directed  out  of  the  Defense  Advanced  Research  FVojects  Agency  (DARPA)  with 
contract  administration  provided  by  the  Air  Force  Electronic  Systems  Division 
and  sponsored  by  the  Department  of  Defense  (DoD)  through  the  DoD  Consolidated 

Softwaure  Initiative.  This  Agreement  is  entered  into  as  of  this _ 

day  of _ ,  19 _ ,  by  and  between  the  STARS  program  and 

_ (AfRliate).  For  purposes  of  this 

Agreement,  the  term  Affiliate  is  used  generically  to  include  any  entity  of 
any  kind,  or  its  employees  or  agents. 

The  parties  agree: 

1.  The  STARS  program  in  discharging  its  obligations  to  the  DoD  may 
have  access  to  proprietary  information  belonging  to  third  parties. 

The  STARS  program’s  mission  is  to  accelerate  the  paradigm  shift  to 
megaprogramming  -  a  process-driven,  domain -specific  reuse-based, 
technology  supported  ways  of  doing  business.  Instances  may  occur 
where  the  aforementioned  mformation  or  technology  will  be  held  as 
proprietary  to  the  U.S.  Government. 

2.  The  Affiliate,  in  connection  with  the  work  of  STARS,  may  have 
access  to  STARS,  third  party  proprietary  mformation,  or  to 
Government  information  designated  "For  Official  Use  Only".  The 
foregoing  described  information  or  technology  shall  be  disclosed 
within  the  STARS  program  on  a  "need  to  know"  basis  and  shall  not 
be  disclosed  outside  of  STARS  without  specific  written  authorization 
from  the  STARS  program  office  and  the  Electronic  Systems  Division 
(ESD)  Public  Affairs  Office. 

3.  Any  information  disclosed  to  the  Affiliate  ahsdl  not  be  deemed  to  be 
confidential  or  proprietary  and  the  Affiliate  shall  have  no  obligation 
with  respect  to  any  such  information  which: 

a.  was  known  to  STARS  or  to  the  Affiliate  and  unrestricted  at  the 
time  it  was  submitted  by  a  third  party,  or 

b.  was  previously  cleared  for  public  release  through  the  DARPA 
STARS  Program  Manager  or  the  S'fARS  program  office 
(ESD/AVS)  or  cleared  through  the  ESD  Public  Affairs,  or 

c.  is  in  the  process  of  being  cleared  for  public  release  through 
ESD/AVS  or  the  ESD  Public  Affairs,  or 

d.  is  received  by  the  Affiliate  from  another  third  party  without 
restrictions  and  without  breach  of  the  agreement  with  the 
initial  disclosure. 


.Mfiliate  -  3 


4.  In  the  case  of  STAES  information  designated  "Distribution  Statement 
C,"  the  Affiliate  will  be  relieved  of  the  limitations  imposed  herein 
upon  receipt  of  specific  written  authorisation  or  removal  of  the  said 
designation  by  the  STARS  Program  Office  (ESD/AVS). 

5.  Upon  ending  affiliation  with  STARS,  the  Affiliate  will  not,  either  in 
whole  or  part,  take  or  keep  any  drawings,  blueprints,  doctunents, 
computer  programs,  (.ompilations  or  technical  data,  specifications 
or  other  records  of  auy  nature  (whether  written  or  in  machine 
readable  form)  proprietary  to  STARS  or  to  any  third  party,  or  any 
Government  information  designated  'Tor  Official  Use  Only",  or  any 
reproductions  of  any  of  the  foregoing  described  information. 


Affiliate 

By: _ 

Date: _ 


STARS 

By: _ 

Date: _ 
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Software  Technology  for  Adaptable  Reliable  Systems  (STARS) 
Affiliates  Questionnaire 


Note:  If  you  need  additional  space,  use  the  back  of  this  questionnaire,  or  additional  sheets. 

1.  Company/Organizadcn  Name _ 

Division/Group/Organization _ 


2.  Primary  Contact; 

Name; _ 

Address: 


Phone:_ 

FAX; _ 

Internet: 


3.  What  level  of  STARS  affiliation  do  you  want? 

a.  Technology  Transfer 

b.  Prime  (Circle  preferred  Prime  -  Boeing,  IBM,  Unisys) 


4. 


What  is  your  CompanyVOrganization's  ^/rimary  business  area? 
(Mark  all  that  art*  applicable) 

a.  Systems 

b.  Software 

c.  Hardware 

d.  Manufacturing 

e.  Consulting 

f.  Systems  Integration 

g.  Other  (please  specify) 
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5.  Does  your  company/organization  (please  specify  which)  have  an  active  technology 
receptor  organization? 

6.  If  yes  to  question  5.  please  provide  contact  information: 

Name: _ 

Address: _ _ _ 


Phone: 


7.  Please  describe  your  company’s/organization’s  primary  area  of  interest  in  software 
engineering  technology. 


8.  Please  describe  how  being  a  STARS  Affiliate  can  best  serve  the  needs  of  your  organi¬ 
zation  (i.e.,  in  what  area  are  you  interested  in  working  with  STARS) 


9.  Comments  (please  provide  any  additional  information,  views,  or  questions  you  may  have): 


10.  Please  attach  a  one-page  position  paper  describing  area(s)  of  greatest  interest  where 
cooperative  development  would  be  mutually  beneficial  and  a  short  resume*  for  each 
participant. 
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STARS  NEWSLETTER 
MAILING  LIST 

The  STARS  Newsletter  continually  updates  its  mailing 
list  with  new  additions  and  changes  of  place  of 
emplo3rment  or  residence.  To  be  added  to  the  mailing 
list  or  to  have  your  mailing  address  changed,  please  fill 
out  this  form  and  mai]  it  to: 

STARS  Technology  Center 
Suite  400 

401  North  Randolph  Street 
Arlington,  Va.  22203 

□  New  Addition  to  List  □  Change  of  Address 

□  Mr.  □  Mrs.  □  Ms.  □  Other 

Name _ 

Organization/Company _ _ _ 

Address _ 

City _ State _ Zip _ 

Telephone _ - _ - _ 

E-Mail  Address _ 
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DEMONSTRATIONS 


STARS  Technology  Center  (STC)  Demonstrations 

Beginning  early  in  1992,  demonstrations  at  the  STC  will 
be  held  on  the  fourth  week  of  every  month. 

For  information  on  what  is  to  be  demonstrated,  as  well 
as  on  which  day  of  the  week  it  will  be  demonstrated,  call 
the  STC  Demonstrations  Coordinator  at  (703)  243-8655. 
Initially,  demonstrations  will  be  provided  in  response  to 
requests. 

Refer  to  the  attached  map  for  the  location  of  the  STC. 
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HOW  TO  OBTAE^  ITEMS  FROM  THE  DEFENSE 
TECHNICAL  INFORMATION  CENTER  (DUC) 

OR 

FROM  THE  NATIONAL  TECHNICAL  INFORMATION 

SERVICE  (NTIS) 


DTIC  ccntains  items  that  are  not  releasable  to  the 
general  public.  To  obtain  items  firom  DTIC,  you  must  be 
government  or  a  contractor  and  be  a  registered  DTIC 
user.  Please  refer  to  the  information  provided  below  or 
contact  DTIC  for  details. 

Defense  Technical  Information  Center 
Cameron  Station 
Alexandria.  Va.  22304^145 
Tel:  (703)  274-7633 

The  general  public  can  obtain  items  approved  for  general 
release  from  ITTIS.  Items  can  be  ordered  through  the 
mail  or  over  the  phone.  A  variety  of  payment  options  is 
available. 

NTIS 

5285  Port  Royal  Road 
Springfield.  Va.  22161-0001 
Tel:  (800)  553-NTIS  (553-6847) 

(703)  487-4650 
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Directions  to  STARS  Technology  Center 


Directions  to  STARS  Technologj'  Center 


ACRONYMS  USED  IN  THESE  PROCEEDINGS 


AAA 

ACAS 

ADA 

AF 

AFS 

AIB 

AIL 

AIX 

AIX 

AJPO 

ALOAF 

AMS 

ANS 

ANSI 

APP 

AFPUA 

ARCS 

ASIS 

ASSET 

ASW 

AXIS 


Artifacts,  Agents,  and  Activities 
Application  Control  Architecttire  Services 
Programming  language 
Air  Force 


A  distributed  product  of  Tramsarc 
Action  Item  Browser 
ASSET  Interchange  Language 

IBM  Advanced  Interactive  Executive  op>erating  system 

Advanced  Interactive  operating  system 

Ada  Joint  Program  OfBce 

ASSET  Library  Open  Architecture  Framework 

ASSET  Management  System 

Artificial  Netiral  Systems;  American  National  Standard 

American  National  Standards  Institute 

Application  Portability  Profile 

Ada  Process  Programming  Language  based  on  Aspen 

Automated  Reusable  Components  System 

Ada  Semantic  Interface  Specification 

ASSET  Source  for  Software  Engineering  Technology 

Anti-Submarine  Warfare 

A  Tool  Integration  Standard  (DEC);  Atherton  Tool  Integration  Service 


BMS  Broadcast  Message  Service 


C2 

C3 

CAIS-#x 

CALS 

CAMP 

CAPE 

CARDS 

CASE 

cc 

ccc 

CCPDSR 

CCITT 

CDD 

CDIF 

CDRL 

CECOM 

CEPA 

COM 

CIM 

CTS 

CLIPS 

CM 

CMM 

CODASYL 

COHESION 


Command  and  Control 
Command,  Control  and  Communication 
Common  APSE  Interface  Set  •  Revision  A 
Computer-Aided  Acquisition  and  Logistics  Support 
Common  Ada  Missile  Packages 
Computer  Aided  Project  Engineering 
Central  Archive  for  Reusable  Defense  Software 
Computer  Aided  Software  Engineering 
Configuration  Control 

Change  and  Configuration  Control  (Product  name) 

Command  Center  Processing  and  Display  System  Replacement 
Consultative  Committee  for  ITT  Corp. 

Common  Data  Dictionary 
CASE  Data  Interchange  Format 
Contract  Data  Requirements  List 

Communications  and  Electronics  Command  (U.S.  Army) 

Geanroom  Engineering  Process  Assistant 

Computer  Graphics  Metafile 

Corporate  Information  Management 

CASE  Integration  Services  committee 

A  NASA  expert  system  shell  •  C  language 

Configuration  Management 

Capability  Maturity  Model 

Conference  On  Data  Systems  Languages 

A  digital  software  environment  product 
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CONOPS  CONcept  of  Operationa 

COTS  Commercial,  Off-The-Shelf 

CRDA  Cooperative  Reaearch  and  Development  Agreements 


DARPA 

DC 

DCE 

DDR&E 

DEC 

DISA/CIM 

DoD 

DSSA 

DTIC 


Defense  Advanced  Research  Projects  Agency 
Data  Collection 

Distributed  Computing  Environment 
Design  Development  Research  &  Engineering 
Digital  Equipment  Corporation 

Defense  Information  Systems  Agency/Center  for  Information  Management 

Department  of  Defense 

Domain  Specific  Software  Architecture 

Defense  Technical  Information  Center 


E-SLCSE 

EAST 

ECMA 

ECP 

EE 

EIA 

EIS 

ER 

ERA 


SLCSE  commercialization  effort 
European  Advanced  Software  Technology 
European  Computer  Manufacturers  Associations 
Engineering  Change  Proposal 
Electrical  Engineering 
Electrical  Indvistries  Association 
Engineering  Information  System 
Entity  Relationship 
Encity-Relation-Attribute 


FAR 

FCDSSA 

FFRDC 

FIM 

FJAG 

FRAC 

FS 

FT 

FTAM 

FTP 


Federal  Acquisition  Regulation 

Fleet  Combat  Directorate  Systems  Support  Activity 

Federally  Funded  Research  and  Development  Center 

Framewoi^  Information  Model 

Frameworh  Joint  Activity  Group 

Frameworic  Requirements  and  Criteria 

Fraction  of  Savings 

Fraction  of  ‘Hme 

OSI  File  Transfer  Access  and  bianagement 
TCP/IP  File  Transfer  Protocol 


GCC 

GIE 

GKS 

GNMP 

GOSIP 

HP 

HPCC 


Generic  Command  Center 

Groupement  dlnterets  Eoonomiques 

Graphical  Kernel  System 

Government  Network  Management  Program 

Government  Open  System  Interconnection  Protocol 

Hewlett  Packard 

Hi^  Performance  Computers  and  Communication 


I&T 

I/O 

ID 

IDA 

WE 

IEEE 

IGES 

IM 

IM 

IOC 

DdCON 


Integration  &  Test 

Input/Output 

IDentification 

Institute  for  Defense  Analysis 
Interactive  Development  Environments 
Institute  of  Electrical  and  Electronics  Engineers 
Initial  Graphics  Exchange  Specification 
Information  Management 
Information  Model 
Initiai  Operationa]  Capability 
Informatioa  Modeling  CONvergence 
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IS&D  Independent  Research  &  Development 

IRAQ  International  Requirements  And  Criteria 

IRDS  Information  Resource  Dictionary  System 

ISAM  Indexed  Sequential  Acces"  Method 

ISRS  Integrated  Software  Engineering  Environment 

ISO/TEC  JTCl  International  Standards  Organization/Intemational  Electrotechnical  Commission 


Joint  Technical  Committee 

ISF  •  6  International  Software  Process  Working  group  No.  6 

ISSI  International  Software  Systems,  Inc. 

rW  CASE  International  Working  group  on  CASE 


JLC 


Joint  Logistics  Commanders 


KDSI  Thousands  of  Delivered  Source  Instructions 

KI  Knowledge  Information 


LAN  Local  Area  Network 

LOC  Lines  Of  Code 


MCCR  Mission-Critical  Computer  Resources 

ME  Mechanical  Engineering 

MFPL  Message  Format  Processing  Language 

MIL-STD-2167A  Military  standard  for  defense  systems  software  development 

MIS  Management  Information  Systems 

MTT  Massachusetts  Institute  of  Technology 

MLS  MultiLevel  Secure 

MM  Man  Months 

MTV  Message  Translatian  and  Validation 

MVP  Multi-View  Process  modeling  project 

MVP-L  MVP  Language 


NASA 

NATO 

NAVAIR 

NBCD 

NCCPM 

NCS/RPC 

NFS 

NGCR 

NIST 

NOSC 

NRAC 

NTIS 

NTSC 


National  Aeronautics  and  Space  Administration 
North  Atlantic  Treaty  Organization 
NAVal  AIR  Systems 

Network-Based  Collaborative  Development 
Navy  Command  and  Control  Process  Model 
Network  Computing  Servicea/Remote  Procedure  Call 
Network  File  System 

Next  Generation  Computer  Resources  (navy  program) 
National  Institute  of  Standards  and  Technology 
Naval  Ocean  Systems  Center 
NATO  Requirements  and  (Triteiia 
National  Technical  Information  Service 
Navy  Training  Systems  Center 


OAF 

OCD 

ODA/ODIF 

OMG 

OMS 

OS 

OSP 

OSI 

OTS 


Open  Architecture  Framework 

Operational  Concept  Document 

Office  Document  Architecture/Interchange  Format 

Object  Management  Group 

Object  Management  System 

Operating  System 

Open  Software  Foundation 

Open  Systems  Interconnectioa  (ISO  standard) 

Off-The^elf 
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P1175 

PAL 

pas 

PCTS 

PDAG 

PDES 

PDSS 

PRIGS 

PM 

PM 

PMDB 

PXHD 

POSK 

PPL 

FREIS 

PREIS 

PRISM 

PSE 

PSESWG 

PSLOPPL 

Q/I 

QA 

RAASP 

RAPID 

RDA 

RDBMS 

READS 

RIG 

RJAG 

RLF 

RMP 

RNTDS 

ROAMS 

ROOD 

ROI 

RPC 

S/W 

SADT 

SAIC 

SBIR 

SCPM 

SDE 

SDIO 

SDP 

SE 

SEE 

SEI 

SE^UTECH 
SEPG 
SETA  2 
SFGL 


A  standard  reference  model  for  computing  system  tool  interconnection 

Process  Asset  Library 

Portable  Common  Interface  Set 

Portable  Common  Tools  Environment 

Process  Definition  Advisory  Group 

Product  Data  Exchange  Specification 

Post-Deployment  Software  Support 

Programmer’s  Hierarchical  Interactive  Graphics  System 

Process  Management 

Process  Model 

Project  Master  DataBase  (TRW  ER&D  project  name) 

Process  Operational  Concept  Document 
Portable  Operating  System  Interface 
Process  Programming  Language 
PRctotype  Engineering  Information  System 
Policy  Representation  using  PREIS 
Portable  Reusable  Integrated  Software  Modules 
Project  Support  Environment 

Project  Support  Environment  Standards  Working  Group 
Process  Support  Language/Process  Programming  Language 

Question/Issue 
Quality  Assurance 

P.eusable  Ada  Avionics  Software  Package 

Reusable  Ada  Products  for  Information  systems  Development 

Remote  Database  Access 

Relational  DataBase  Management  System 

Requirements  Entry  Allocation  Decomposition  System 

Reuse  library  Interoperability  Group 

Reuse  Joint  Activities  Group 

Reusability  Library  Framework 

Risk  Management  Plan 

Restructured  Navy  Tactical  Data  System 

Reusable  Object  Access  Macagement  System 

Reuse  Operational  Concept  Document 

Return  On  Investment 

Remote  Procedure  Call 

Software 

Structured  Analysis  and  Design  Techniques 
Science  Applications  International  Corporation 
Small  Business  Innovative  Reseaioh 
STARS  Composite  Process  Model 
Software  Development  Environment 
Strategic  Defense  Initiative  Office 
Software  Development  Plan 
Software  Engineering 
Software  Enginerring  Environment 
Software  Engineering  Institute 
A  consortiam 

Software  Engineering  Process  Group 

Second  international  Symposium  on  Environments  and  tools  for  Ada 
Name  of  French  software  company 
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SGML 

SIM 

SJAG 

SLCSE 

SMTP 

SOCD 

SOP 

SPC 

SPDL 

SPMS 

SPO 

SPS 

SQL 

SRL 

SSP 

STARS 

STEP 

sw 

SWAP 

SWTP 

TCP/IP 

TELNET 

TFAINFS) 

TT 

U1 

UIMS 

V/M/S 

VAX 

VMS 

VTP 

WAN 

X 

X3H3 

X3H4 

X3H6 

X.400 

X.600 

xn 

XVT 


Standard  Generalized  Markup  Language 

SEE  Information  Model 

SEE  Joint  ActiTities  Group 

Software  Life  Cycle  Support  Environment 

TCP/IP  Simple  Mail  Transfer  Protocol 

SEE  Operational  Concepts  Document 

Standard  Operating  Procedures 

Software  Productivity  Consortium 

Standardized  Page  Descriptor  Language 

Software  Process  Management  System 

Systems  Program  0£5ce 

Software  Productivity  Solutions 

Standard  Query  Language;  SQL  database  language 

Software  Reuse  Library 

STARS  Standards  Portfolio 

Software  Tcebnology  for  Adaptable.  Reliable  Systems 

Spec  To  Executable  Program;  Standard  for  Exchange  of  Product  model  data 

Software 

Software  Action  Plan 
Software  Technology  Plan 

Transmission  Control  Protocol/Intemet  Protocol 
TCP/IP  interactive  session  protocol 
Transparent  File  Access 
Technology  Transfer 

User  Interface 
UI  Management  System 

Vlsion/Miasion/Strategy 
DEC  product 

VAX  Virtual  Monitor  System 
OSl  Virtual  Termiiud  Protocol 

Wide  Area  Networit 

X  Window  System 

ANSI  technical  committee  on  graphics 
ANSI  Technical  committee  on  IRDS 

ANSI  Technical  committee  on  CASE  tool  integration  models 

OSI  message  handling  system 

OSl  network  directory  services 

X/open  Transport  Interface 

X  Virtual  Terminal;  extensible  Virtual  Toolkit 
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